Created attachment 2880 [details] enable --allnoconfig only if split configure is requested related to issue #8289 poky-commit: # 44cf077ac146a568e28d7a69da4a4f48c55cd2cf When kernel-yocto.bbclass finds a file named 'defconfig' in its workdir, it will switch configme to '--allnoconfig' mode, which says all optional features should be disabled. The defconfig we use, has been generated with 'make savedefconfig' part of kconfig. It relies on kconfig default values and only keeps those config values which differ from the defaults and/or are not automatically activated by other options. We use the KBUILD_DEFCONFIG option, which at the moment is the right option for us. Hence I argued with the maintainer of our kernel tree, that we need a full defconfig that sets all option, incl. the redundant one. But his argument was that I'm wrong since the kernel is always right. FYI: I was able to make it to work using 'KCONFIG_MODE='--alldefconfig'. That's where I lost the argument. Indeed 'defconfig' is a term coined by the kconfig, and obviously comes with some semantics different from kernel-tools. So evtl, there is a naming problem here. EXAMPLE: this actually works, despite me expecting it to have used allnoconfig, since I explicitly wanted to have things under control: SRC_URI += file://base.cfg; file://fragment.cfg I suggest to enabling '--allnoconfig' only if people explicitly switch to the baseline/fragment way of split configs. Or the inversion disable it if there is a defconfig in the workdir. A change it semantics probably has to go with an explicit naming change, as a heads up to the users
in the exmple: base.cfg is simply a renamed defconfig generated with make savedefconfig
There's nothing to change here. The entire point of the ability to control the KCONFIG mode is that there's no single choice that can meet all use cases. There are as many known use cases that do use full .config and defconfigs, and they want/need/use the allnoconfig to set a baseline. What I can do, is emit a warning, and do some checking on the resulting config to make that warning even better (which is already in progress for 2.1), but there's no compelling reason to change the default.
We probably have to agree to disagree, :-) Intuitively, I would expected to get the same output when using a defconfig. Independent form whether I build the kernel myself or through yocto. > There's nothing to change here. The entire point of the > ability to control the KCONFIG mode is that there's no single > choice that can meet all use cases. But then keep to the default behaviour, and let those take actions that divert from the default. Here the code-paths in the kernel Kconfig. The kernel actually uses default options to fill in the holes. make foobar_defoconfig: "@scripts/kconfig/conf --defconfig=arch/arm/configs/foobar_defconfig Kconfig from scripts/kconfig/conf.c: case alldefconfig: conf_set_all_new_symbols(def_default); break; ..... case defconfig: conf_set_all_new_symbols(def_default); break; > There are as many known use cases that do use full .config > and defconfigs, and they want/need/use the allnoconfig to > set a baseline. When the defconfig hosted by the yocto recipe, it surely becomes outdated upon kernel upgrades, and you don't want to enable all the new shiny features coming with the upgrade. Again, people using recipe hosted defconfig must be aware of of the problem, and hence are more sensible to take precautions. But since this is probably the most frequent use case, -- KBUILD_DEFCONFIG feature has been added in 1.8 --, it might affect a lot of people when changing the default. What about this: file://defconfig;conf_mode=allnoconfig - emit a warning if allnoconfig is not given? - enable allnoconfig only when defconfig is listed in SRC_URI? Another issue is that the mode is enabled base on a file name. My first naive approach using fragments was: SRC_URI = "file://base.cfg; file://dtb-append.cfg" In that case allnoconfig was not enabled since I renamed the defconfig. It's a heuristic and it can be difficult to debug. Of course I knew the delta that I changed, but I was surprised that the file name actually matters BTW: I was going through the files in yocto-kernel-cache repository. It's quite impressive and I probably might use it in the future, once all our platforms are built from the same tree http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/tree/?h=yocto-4.1
Moving to 2.2 M1 to go along with other kernel configuration changes.
This will change with the enablement of fragments for more kernel variants. So moving to 2.5, but it may be fixed with 2.4 (and I'll update accordingly then).
Bulk move from 4.99 or 0.00 to 5.99
Re-open with the current behaviour and full build details if this is still a problem.