On Mon, Feb 12, 2018 at 3:21 PM, Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx> wrote: > 'syncconfig' in a more proper name Wonder if --update-config-files-for-build or something would be an even better name. Kinda tough to compress it into something that adheres to *nix terseness while making it somewhat clear what kind of stuff it deals with. :P Cheers, Ulf On Mon, Feb 12, 2018 at 3:21 PM, Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx> wrote: > 2018-02-12 21:54 GMT+09:00 Ulf Magnusson <ulfalizer@xxxxxxxxx>: >> On Sun, Feb 11, 2018 at 09:42:09PM +0100, Ulf Magnusson wrote: >>> On Sun, Feb 11, 2018 at 9:29 PM, Ulf Magnusson <ulfalizer@xxxxxxxxx> wrote: >>> > On Sun, Feb 11, 2018 at 6:56 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >>> >> Another case I mentioned before that I just want to make sure we don't >>> >> reintroduce the problem of getting "stuck" with a bad .config file. >>> >> While adding _STRONG support, I discovered the two-phase Kconfig >>> >> resolution that happens during the build. If you selected _STRONG with >>> >> a strong-capable compiler, everything was fine. If you then tried to >>> >> build with an older compiler, you'd get stuck since _STRONG wasn't >>> >> support (as detected during the first Kconfig phase) so the >>> >> generated/autoconf.h would never get updated with the newly selected >>> >> _REGULAR). I moved the Makefile analysis of available stack-protector >>> >> options into the second phase (i.e. after all the Kconfig runs), and >>> >> that worked to both unstick such configs and provide a clear message >>> >> early in the build about what wasn't available. >>> >> >>> >> If all this detection is getting moved up into Kconfig, I'm worried >>> >> we'll end up in this state again. If the answer is "you have to delete >>> >> autoconf.h if you change compilers", then that's fine, but it sure >>> >> seems unfriendly. :) >>> > >>> > Did you mean include/config/auto.conf? That's the one that gets >>> > included by the Makefiles. >>> > >>> > If the feature detection is moved into Kconfig, you should only need >>> > to rerun the configuration (make menuconfig/oldconfig/olddefconfig) if >>> > you change the compiler. That will update .config while taking the new >>> > features into account, and then the second phase during 'make' will >>> > update include/config/auto.conf from .config. >>> > >>> > That second Kconfig phase generates include/generated/autoconf.h and >>> > include/config/. The include/config/ directory implements dependencies >>> > between source files and Kconfig symbols by turning the symbols into >>> > (empty) files. When building (during the "second phase"), Kconfig >>> > compares .config with include/config/auto.conf to see what changed, >>> > and signals the changes to 'make' by touch'ing the files corresponding >>> > to the changed symbols. The idea is to avoid having to do a full >>> > rebuild whenever the configuration is changed. >>> > >>> > Check out scripts/basic/fixdep.c as well if you want to understand how it works. >>> > >>> > Cheers, >>> > Ulf >>> >>> By the way: >>> >>> That second phase is also a "normal" Kconfig run in the sense that it >>> does all the usual dependency checking stuff. Even if .config doesn't >>> respect dependencies, include/config/auto.conf will. So I think you >>> might not even need to rerun the configuration (though .config will be >>> out-of-date until you do). >>> >>> Cheers, >>> Ulf >> >> Seems you'd have to rerun the configuration, because >> include/config/auto.conf is only regenerated if it's older than .config. >> >> Here's the bit in the root Makefile that does it (KCONFIG_CONFIG is >> .config). >> >> # If .config is newer than include/config/auto.conf, someone tinkered >> # with it and forgot to run make oldconfig. >> # if auto.conf.cmd is missing then we are probably in a cleaned tree so >> # we execute the config step to be sure to catch updated Kconfig files >> include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd >> $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig >> >> silentoldconfig is a terrible name. What it actually does is run that >> "second phase" stuff. > > Right. This is a historical misnomer. > > My plan is, as already posted below, to rename 'silentoldconfig' to 'synconfig' > https://lkml.org/lkml/2018/1/17/1359 > > > >> Pretty sure that comment lies by the way. 'make oldconfig' doesn't >> update include/config/auto.conf. It's probably outdated. > > Good catch. > > >> >> I wonder if it would be simpler to just always run silentoldconfig when >> building. It's not that slow on my system: >> >> $ export ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` >> $ time scripts/kconfig/conf --silentoldconfig Kconfig >> >> real 0m0.167s >> user 0m0.162s >> sys 0m0.004s >> >> That'd both simplify the Makefiles, and make sure that the latest >> features are always used if you do feature testing in Kconfig. >> >> I don't know how strongly people feel about a few tenths of a second >> though. > > > No. NACK. > > silentoldconfig touches include/generated/autoconf.h > so, files that depend on it will be re-compiled, unnecessarily. > > > silentoldconfig ( 'syncconfig' in a more proper name) > should be run only when necessary. > > > > > -- > Best Regards > Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
