For an end user, when he/she wants to edit the kernel config: $ bitbake virtual/kernel -cmenuconfig $ bitbake virutal/kernel He has to do this again for another build or use the foo.scc and foo.cfg, the problem is foo.scc and foo.cfg is not very easy to use. If would be better if: 1) The kernel can build from an existing .config, for example, use KERNEL_DOT_CONFIG="/path/to/.config" to specify the config and build it. Or: 2) The kernel can generate a .scc and .cfg after -cmenuconfig and print a hint message on how to enable it from local.conf, .bb, or .bbappend.
(In reply to comment #0) > For an end user, when he/she wants to edit the kernel config: > > $ bitbake virtual/kernel -cmenuconfig > > $ bitbake virutal/kernel > > He has to do this again for another build or use the foo.scc and foo.cfg, > the problem is foo.scc and foo.cfg is not very easy to use. If would be > better if: > > 1) The kernel can build from an existing .config, for example, use > KERNEL_DOT_CONFIG="/path/to/.config" to specify the config and build it. We definitely will not do this .. No more kernel configuration inputs! :) There are already enough mechanisms and inputs in place to do this via a defconfig. We want fragments, not full .config's or defconfigs to be built. We already have the ability to do defconfigs on the SRC_URI and to point to an in-tree defconfig. We also have the ability to vary the configuration mode used to process the defconfig. There's no need to add something else and point to a .config. If there's a but in the current support, we can tweak it, but the building of a full .config that is outside of a kernel tree .. is not something a proper kernel workflow should do. > > Or: > > 2) The kernel can generate a .scc and .cfg after -cmenuconfig and print a > hint message on how to enable it from local.conf, .bb, or .bbappend. This is something that devtool should handle, not the kernel classes. There's already a way to save a defconfig in the kernel classes (savedefconfig) and within the bbclass there's little need to get much more complex to that. To take a modified config and export fragments is a good idea, but that is something that we've talked about in devtool context (diffconfig), versus the core classes. So I agree the concept has merit, but needs to be implemented in the right place. Needless to say. There's already kernel configuration changes planned and in flight for 2.2, so do not start any implementation on things like this, without discussing the design in detail with me first.
As there is already a way to specify a defconfig in the SRC_URI, and there are plans for updating the kernel configuration, let's revisit this with a new enhancement that is more appropriate to devtool, if that tool does not meet the requirements.