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-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
