| Message ID | 1423921601-20473-1-git-send-email-bos@je-eigen-domein.nl |
|---|---|
| State | Changes Requested |
| Headers | show |
Floris, All, On 2015-02-14 14:46 +0100, Floris Bos spake thusly: > Adds configuration option to merge additional kernel configuration files > to the main kernel configuration using support/kconfig/merge_config.sh > > For use-cases in which it is desired to build a custom Linux kernel based on > the defconfig of the target device, but with a couple extra options/modules > enabled. > > Changes v1 -> v2: > > Use the merge_config.sh bundled with buildroot, instead of the one > bundled with the kernel, as older kernel versions do not have it. This "Changes" blrub should after the '---' line, below. > Signed-off-by: Floris Bos <bos@je-eigen-domein.nl> > --- > linux/Config.in | 6 ++++++ > linux/linux.mk | 3 +++ > 2 files changed, 9 insertions(+) > > diff --git a/linux/Config.in b/linux/Config.in > index c981493..afa68b0 100644 > --- a/linux/Config.in > +++ b/linux/Config.in > @@ -161,6 +161,12 @@ config BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE > help > Path to the kernel configuration file > > +config BR2_LINUX_KERNEL_CONFIG_FRAGMENTS > + string "Additional configuration fragment files" > + help > + A space-seperated list of kernel configuration fragment files, > + that will be merged to the main kernel configuration file. > + > # > # Binary format > # > diff --git a/linux/linux.mk b/linux/linux.mk > index 29f59e8..665bc0b 100644 > --- a/linux/linux.mk > +++ b/linux/linux.mk > @@ -39,6 +39,7 @@ endif # -rc > endif > > LINUX_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH)) > +LINUX_KERNEL_CONFIG_FRAGMENTS = $(call qstrip,$(BR2_LINUX_KERNEL_CONFIG_FRAGMENTS)) > > LINUX_INSTALL_IMAGES = YES > LINUX_DEPENDENCIES += host-kmod host-lzop > @@ -178,6 +179,8 @@ define LINUX_CONFIGURE_CMDS > $(INSTALL) -m 0644 $(KERNEL_SOURCE_CONFIG) $(KERNEL_ARCH_PATH)/configs/buildroot_defconfig > $(TARGET_MAKE_ENV) $(MAKE1) $(LINUX_MAKE_FLAGS) -C $(@D) buildroot_defconfig > rm $(KERNEL_ARCH_PATH)/configs/buildroot_defconfig > + $(if $(LINUX_KERNEL_CONFIG_FRAGMENTS), > + $(TOPDIR)/support/kconfig/merge_config.sh -m -O $(@D) $(@D)/.config $(LINUX_KERNEL_CONFIG_FRAGMENTS)) As Baruch suggested earlier, this could be usefull to have such a feature available to all our kconfig-packages: linux, busybox, uclibc and barebox. Granted, when you did your patch, the kernel was not yet using the kconfig-package infra. But it now does (since Thomas P. applied the series a few minutes ago! ;-) ) Could you rework your patch to integrate this feature in the kconfig-package infra, please? Something like (shortlog-like): kconfig-package: add support for config fragments linux: add option to specify config fragments busybox: add option to specify config fragments uclibc: add option to specify config fragments barebox: add option to specify config fragments As for how to pass the the config fragments: just pas them all in the _KCONFIG_FILE variable, and in package/pkg-kconfig.mk, replace line 54 with something like (untested): support/kconfig/merge_config.sh -m -O $(@D) $$($(2)_KCONFIG_FILE) Callers will have to pass the base config file first and any fragment asfter that, like so: LINUX_KCONFIG_FILE = $(KERNEL_SOURCE_CONFIG) $(call qstrip,$(LINUX_KERNEL_CONFIG_FRAGMENTS)) (Of course, we are again hitting the singular option that accepts multiple entries, and in retrospect, we should have called it just FOO_KCONFIG_FILES. We can change that, but later (after we apply the support for fragments). Regards, Yann E. MORIN. > $(if $(BR2_arm)$(BR2_armeb), > $(call KCONFIG_ENABLE_OPT,CONFIG_AEABI,$(@D)/.config)) > $(if $(BR2_TARGET_ROOTFS_CPIO), > -- > 1.9.1 > > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Hi, On 02/14/2015 05:59 PM, Yann E. MORIN wrote: > On 2015-02-14 14:46 +0100, Floris Bos spake thusly: >> Adds configuration option to merge additional kernel configuration files >> to the main kernel configuration using support/kconfig/merge_config.sh >> >> For use-cases in which it is desired to build a custom Linux kernel based on >> the defconfig of the target device, but with a couple extra options/modules >> enabled. >> >> Changes v1 -> v2: >> >> Use the merge_config.sh bundled with buildroot, instead of the one >> bundled with the kernel, as older kernel versions do not have it. > This "Changes" blrub should after the '---' line, below. > >> Signed-off-by: Floris Bos <bos@je-eigen-domein.nl> >> --- >> linux/Config.in | 6 ++++++ >> linux/linux.mk | 3 +++ >> 2 files changed, 9 insertions(+) >> >> diff --git a/linux/Config.in b/linux/Config.in >> index c981493..afa68b0 100644 >> --- a/linux/Config.in >> +++ b/linux/Config.in >> @@ -161,6 +161,12 @@ config BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE >> help >> Path to the kernel configuration file >> >> +config BR2_LINUX_KERNEL_CONFIG_FRAGMENTS >> + string "Additional configuration fragment files" >> + help >> + A space-seperated list of kernel configuration fragment files, >> + that will be merged to the main kernel configuration file. >> + >> # >> # Binary format >> # >> diff --git a/linux/linux.mk b/linux/linux.mk >> index 29f59e8..665bc0b 100644 >> --- a/linux/linux.mk >> +++ b/linux/linux.mk >> @@ -39,6 +39,7 @@ endif # -rc >> endif >> >> LINUX_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH)) >> +LINUX_KERNEL_CONFIG_FRAGMENTS = $(call qstrip,$(BR2_LINUX_KERNEL_CONFIG_FRAGMENTS)) >> >> LINUX_INSTALL_IMAGES = YES >> LINUX_DEPENDENCIES += host-kmod host-lzop >> @@ -178,6 +179,8 @@ define LINUX_CONFIGURE_CMDS >> $(INSTALL) -m 0644 $(KERNEL_SOURCE_CONFIG) $(KERNEL_ARCH_PATH)/configs/buildroot_defconfig >> $(TARGET_MAKE_ENV) $(MAKE1) $(LINUX_MAKE_FLAGS) -C $(@D) buildroot_defconfig >> rm $(KERNEL_ARCH_PATH)/configs/buildroot_defconfig >> + $(if $(LINUX_KERNEL_CONFIG_FRAGMENTS), >> + $(TOPDIR)/support/kconfig/merge_config.sh -m -O $(@D) $(@D)/.config $(LINUX_KERNEL_CONFIG_FRAGMENTS)) > As Baruch suggested earlier, this could be usefull to have such a > feature available to all our kconfig-packages: linux, busybox, uclibc > and barebox. > > Granted, when you did your patch, the kernel was not yet using the > kconfig-package infra. But it now does (since Thomas P. applied the > series a few minutes ago! ;-) ) > > Could you rework your patch to integrate this feature in the > kconfig-package infra, please? > > Something like (shortlog-like): > > kconfig-package: add support for config fragments > linux: add option to specify config fragments > busybox: add option to specify config fragments > uclibc: add option to specify config fragments > barebox: add option to specify config fragments > > As for how to pass the the config fragments: just pas them all in the > _KCONFIG_FILE variable, and in package/pkg-kconfig.mk, replace line 54 > with something like (untested): > > support/kconfig/merge_config.sh -m -O $(@D) $$($(2)_KCONFIG_FILE) > > Callers will have to pass the base config file first and any fragment > asfter that, like so: > > LINUX_KCONFIG_FILE = $(KERNEL_SOURCE_CONFIG) $(call qstrip,$(LINUX_KERNEL_CONFIG_FRAGMENTS)) > > (Of course, we are again hitting the singular option that accepts > multiple entries, and in retrospect, we should have called it just > FOO_KCONFIG_FILES. We can change that, but later (after we apply the > support for fragments). Problem I see with passing multiple files in the LINUX_KCONFIG_FILE variable -as opposed to using a separate variable- is that the variable is currently also used as destination file. If you do "make linux-menuconfig", change some settings, do "make linux-updateconfig", the kconfig infrastructure copies .config back to LINUX_KCONFIG_FILE. So would require more extensive modification. Talking about which. I am also not sure how updateconfig should behave in case there are fragments. Should it compute the differences between the original configuration and after the user edited it, and save the changes to the (last) fragment in the list? Is there any good ready-made shell script for comparing .config files that we could use for that? I know that there is diffconfig that comes with the kernel source, but it requires python, and would need to be modified to output in the right format. Yours sincerely, Floris Bos
Floris, All, On 2015-02-14 23:39 +0100, Floris Bos spake thusly: > On 02/14/2015 05:59 PM, Yann E. MORIN wrote: > >On 2015-02-14 14:46 +0100, Floris Bos spake thusly: > >>Adds configuration option to merge additional kernel configuration files > >>to the main kernel configuration using support/kconfig/merge_config.sh [--SNIP--] > >Could you rework your patch to integrate this feature in the > >kconfig-package infra, please? [--SNIP--] > > LINUX_KCONFIG_FILE = $(KERNEL_SOURCE_CONFIG) $(call qstrip,$(LINUX_KERNEL_CONFIG_FRAGMENTS)) [--SNIP--] > Problem I see with passing multiple files in the LINUX_KCONFIG_FILE variable > -as opposed to using a separate variable- is that the variable is currently > also used as destination file. Ah, you're right, of coursei. Nice catch! Then you'll have to introduce a new FOO_KCONFIG_FRAGMENT_FILES. > If you do "make linux-menuconfig", change some settings, do "make > linux-updateconfig", the kconfig infrastructure copies .config back to > LINUX_KCONFIG_FILE. Yes, that's right. > Talking about which. > I am also not sure how updateconfig should behave in case there are > fragments. > Should it compute the differences between the original configuration and > after the user edited it, and save the changes to the (last) fragment in the > list? > Is there any good ready-made shell script for comparing .config files that > we could use for that? > I know that there is diffconfig that comes with the kernel source, but it > requires python, and would need to be modified to output in the right > format. There are three options here: 1- we just copy the .config back to FOO_KCONFIG_FILE, and leave to the user the duty to further strip it if need be; 2- we try to be smart and deal with regenerating a config file that does not contain any of the fragments, and we fail (because that is really complex); 3- we just error out in case fragments are being used, because we don't know how to save a (def)config file in this case (see above: it's really compex). My opinion would be we go with 3 (my prefernce) or 1, not 2. Note that the problem of saving back the (def)config is not due to integrating support for fragments in the kconfig-package infra; your initial patch already exposed that problem (whether the kernel used or not the kconfig-package infra). Regards, Yann E. MORIN.
Yann, Floris, On Sun, 15 Feb 2015 00:20:36 +0100, Yann E. MORIN wrote: > There are three options here: > > 1- we just copy the .config back to FOO_KCONFIG_FILE, and leave to the > user the duty to further strip it if need be; > > 2- we try to be smart and deal with regenerating a config file that > does not contain any of the fragments, and we fail (because that is > really complex); > > 3- we just error out in case fragments are being used, because we don't > know how to save a (def)config file in this case (see above: it's > really compex). > > My opinion would be we go with 3 (my prefernce) or 1, not 2. My preference would also be option (3). Thomas
diff --git a/linux/Config.in b/linux/Config.in index c981493..afa68b0 100644 --- a/linux/Config.in +++ b/linux/Config.in @@ -161,6 +161,12 @@ config BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE help Path to the kernel configuration file +config BR2_LINUX_KERNEL_CONFIG_FRAGMENTS + string "Additional configuration fragment files" + help + A space-seperated list of kernel configuration fragment files, + that will be merged to the main kernel configuration file. + # # Binary format # diff --git a/linux/linux.mk b/linux/linux.mk index 29f59e8..665bc0b 100644 --- a/linux/linux.mk +++ b/linux/linux.mk @@ -39,6 +39,7 @@ endif # -rc endif LINUX_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH)) +LINUX_KERNEL_CONFIG_FRAGMENTS = $(call qstrip,$(BR2_LINUX_KERNEL_CONFIG_FRAGMENTS)) LINUX_INSTALL_IMAGES = YES LINUX_DEPENDENCIES += host-kmod host-lzop @@ -178,6 +179,8 @@ define LINUX_CONFIGURE_CMDS $(INSTALL) -m 0644 $(KERNEL_SOURCE_CONFIG) $(KERNEL_ARCH_PATH)/configs/buildroot_defconfig $(TARGET_MAKE_ENV) $(MAKE1) $(LINUX_MAKE_FLAGS) -C $(@D) buildroot_defconfig rm $(KERNEL_ARCH_PATH)/configs/buildroot_defconfig + $(if $(LINUX_KERNEL_CONFIG_FRAGMENTS), + $(TOPDIR)/support/kconfig/merge_config.sh -m -O $(@D) $(@D)/.config $(LINUX_KERNEL_CONFIG_FRAGMENTS)) $(if $(BR2_arm)$(BR2_armeb), $(call KCONFIG_ENABLE_OPT,CONFIG_AEABI,$(@D)/.config)) $(if $(BR2_TARGET_ROOTFS_CPIO),
Adds configuration option to merge additional kernel configuration files to the main kernel configuration using support/kconfig/merge_config.sh For use-cases in which it is desired to build a custom Linux kernel based on the defconfig of the target device, but with a couple extra options/modules enabled. Changes v1 -> v2: Use the merge_config.sh bundled with buildroot, instead of the one bundled with the kernel, as older kernel versions do not have it. Signed-off-by: Floris Bos <bos@je-eigen-domein.nl> --- linux/Config.in | 6 ++++++ linux/linux.mk | 3 +++ 2 files changed, 9 insertions(+)