2018-02-12 23:53 GMT+09:00 Ulf Magnusson <ulfalizer@xxxxxxxxx>: > 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. I want to use a name that ends with 'config' like any other config targets because: - I want use the same name for scripts/kconfig/conf option and Makefile target to take advantage of 'simple-targets' [1] - I want to use pattern rule to descend into scripts/kconfig/ [2] [1] https://github.com/torvalds/linux/blob/v4.16-rc1/scripts/kconfig/Makefile#L84 [2] https://github.com/torvalds/linux/blob/v4.16-rc1/Makefile#L506 It would be possible to directly descend into scripts/kconfig/ like follows, but I do not have a good reason to break the convention. include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd $(Q)$(MAKE) $(build)=scripts/kconfig update-config-files-for-build > > 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 -- 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
