core/pkg-kconfig: add an option to use olddefconfig
PATCH 1/2 core/pkg-kconfig: add an option to use olddefconfig
Using 'yes "" | make oldconfig' to regenerate a .config file from an existing defconfig does not work reliably in all cases. Specifically, it does not work well with tristate choice entries.
The correct way to do it is to use 'make olddefconfig', but this target is not supported in projects that use an old version of kconfig. As most projects do not use tristate entries, there is no need for them to upgrade.
As a result, add support in the pkg-kconfig infrastructure for both cases, with a configuration entry to select which mode to use.
--- docs/manual/adding-packages-kconfig.txt | 5 +++++ package/pkg-kconfig.mk | 10 ++++++---- 2 files changed, 11 insertions(+), 4 deletions(-)
docs/manual/adding-packages-kconfig.txt +5 -0
@@ -53,6 +53,11 @@ It is mandatory to provide either, but not both: * +FOO_KCONFIG_FILE+ specifies the path to a defconfig or full-config file to be used to configure the package. +* +FOO_KCONFIG_OLDDEFCONFIG+ when set specifies that the 'make' rule to + call with defconfig files is 'olddefconfig'. Only some projects support + it, but the default rule called 'oldconfig' can misbehave when the + config file changes tristate 'choice' entries. + * +FOO_KCONFIG_DEFCONFIG+ specifies the defconfig 'make' rule to call to configure the package.
package/pkg-kconfig.mk +6 -4
@@ -60,8 +60,7 @@ $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES): | $(1)-patch # The specified source configuration file and any additional configuration file # fragments are merged together to .config, after the package has been patched. # Since the file could be a defconfig file it needs to be expanded to a -# full .config first. We use 'make oldconfig' because this can be safely -# done even when the package does not support defconfigs. +# full .config first. $$($(2)_DIR)/.config: $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES) $$(if $$($(2)_KCONFIG_DEFCONFIG), \ $$($(2)_MAKE_ENV) $$(MAKE) -C $$($(2)_DIR) \
@@ -69,8 +68,11 @@ $$($(2)_DIR)/.config: $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES) cp $$($(2)_KCONFIG_FILE) $$(@)) support/kconfig/merge_config.sh -m -O $$(@D) \ $$(@) $$($(2)_KCONFIG_FRAGMENT_FILES) - $$(Q)yes "" | $$($(2)_MAKE_ENV) $$(MAKE) -C $$($(2)_DIR) \ - $$($(2)_KCONFIG_OPTS) oldconfig + $$(if $$($(2)_KCONFIG_OLDDEFCONFIG), \ + $$($2_MAKE_ENV) $$(MAKE) -C $$($(2)_DIR) \ + $$($(2)_KCONFIG_OPTS) olddefconfig, \ + $$(Q)yes "" | $$($(2)_MAKE_ENV) $$(MAKE) -C $$($(2)_DIR) \ + $$($(2)_KCONFIG_OPTS) oldconfig) # If _KCONFIG_FILE or _KCONFIG_FRAGMENT_FILES exists, this dependency is # already implied, but if we only have a _KCONFIG_DEFCONFIG we have to add
Signature · 1 line
2.5.0
PATCH 2/2 linux: use olddefconfig with defconfig files
Use the new option, as the linux kernel will not respect the configuration saved by savedefconfig otherwise.
--- linux/linux.mk | 1 + 1 file changed, 1 insertion(+)
linux/linux.mk +1 -0
@@ -202,6 +202,7 @@ endif LINUX_KCONFIG_FRAGMENT_FILES = $(call qstrip,$(BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES)) LINUX_KCONFIG_EDITORS = menuconfig xconfig gconfig nconfig LINUX_KCONFIG_OPTS = $(LINUX_MAKE_FLAGS) +LINUX_KCONFIG_OLDDEFCONFIG = y # If no package has yet set it, set it from the Kconfig option LINUX_NEEDS_MODULES ?= $(BR2_LINUX_NEEDS_MODULES)
Signature · 1 line
2.5.0
PATCH 1/2 core/pkg-kconfig: add an option to use olddefconfig
In reply to Romain IzardRomain, All,
On 2016-03-25 11:17 +0100, Romain Izard spake thusly:
Quoted 11 lines
Using 'yes "" | make oldconfig' to regenerate a .config file from an existing defconfig does not work reliably in all cases. Specifically, it does not work well with tristate choice entries.
The correct way to do it is to use 'make olddefconfig', but this target is not supported in projects that use an old version of kconfig. As most projects do not use tristate entries, there is no need for them to upgrade.
As a result, add support in the pkg-kconfig infrastructure for both cases, with a configuration entry to select which mode to use.
In fact, we've already discussed this, and we concluded that we would want an automatic behaviour.
I.e. we try to use olddefconfig, and fallback to the yes-trick, like so:
make olddefconfig || { yes "" |make oldconfig; }Care to adapt your patch and respin, please? Of course, your second patch will no longer make sense after that.
In the meantime, I marked your patches as "Changes Requested" in patchwork.
Thanks! ;-)
Regards,
Yann E. MORIN.
Quoted 57 lines
Signed-off-by Romain Izard <[email protected]>--- docs/manual/adding-packages-kconfig.txt | 5 +++++ package/pkg-kconfig.mk | 10 ++++++---- 2 files changed, 11 insertions(+), 4 deletions(-)docs/manual/adding-packages-kconfig.txt +5
-0@@ -53,6 +53,11 @@ It is mandatory to provide either, but not both: * +FOO_KCONFIG_FILE+ specifies the path to a defconfig or full-config file to be used to configure the package. +* +FOO_KCONFIG_OLDDEFCONFIG+ when set specifies that the 'make' rule to + call with defconfig files is 'olddefconfig'. Only some projects support + it, but the default rule called 'oldconfig' can misbehave when the + config file changes tristate 'choice' entries. + * +FOO_KCONFIG_DEFCONFIG+ specifies the defconfig 'make' rule to call to configure the package.package/pkg-kconfig.mk +6
-4@@ -60,8 +60,7 @@ $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES): | $(1)-patch # The specified source configuration file and any additional configuration file # fragments are merged together to .config, after the package has been patched. # Since the file could be a defconfig file it needs to be expanded to a -# full .config first. We use 'make oldconfig' because this can be safely -# done even when the package does not support defconfigs. +# full .config first. $$($(2)_DIR)/.config: $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES) $$(if $$($(2)_KCONFIG_DEFCONFIG), \ $$($(2)_MAKE_ENV) $$(MAKE) -C $$($(2)_DIR) \@@ -69,8 +68,11 @@ $$($(2)_DIR)/.config: $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES) cp $$($(2)_KCONFIG_FILE) $$(@)) support/kconfig/merge_config.sh -m -O $$(@D) \ $$(@) $$($(2)_KCONFIG_FRAGMENT_FILES) - $$(Q)yes "" | $$($(2)_MAKE_ENV) $$(MAKE) -C $$($(2)_DIR) \ - $$($(2)_KCONFIG_OPTS) oldconfig + $$(if $$($(2)_KCONFIG_OLDDEFCONFIG), \ + $$($2_MAKE_ENV) $$(MAKE) -C $$($(2)_DIR) \ + $$($(2)_KCONFIG_OPTS) olddefconfig, \ + $$(Q)yes "" | $$($(2)_MAKE_ENV) $$(MAKE) -C $$($(2)_DIR) \ + $$($(2)_KCONFIG_OPTS) oldconfig) # If _KCONFIG_FILE or _KCONFIG_FRAGMENT_FILES exists, this dependency is # already implied, but if we only have a _KCONFIG_DEFCONFIG we have to addSignature · 6 lines
2.5.0 _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/2 core/pkg-kconfig: add an option to use olddefconfig
Hello,
Quoted 5 lines · Yann E. MORIN
In fact, we've already discussed this, and we concluded that we would want an automatic behaviour.
I.e. we try to use olddefconfig, and fallback to the yes-trick, like so:
Quoted 7 lines
make olddefconfig || { yes "" |make oldconfig; }Care to adapt your patch and respin, please? Of course, your second patch will no longer make sense after that.
In the meantime, I marked your patches as "Changes Requested" in patchwork.
And here is the reason why we want this automatic behavior rather than the explicit FOO_KCONFIG_OLDDEFCONFIG variable that you proposed
Romain: the Linux, Barebox and U-Boot packages, which are some of the main users of kconfig-package infrastructure, have user-configurable versions. Therefore, we don't know if the user will select a recent enough version of the kernel, Barebox or U-Boot with olddefconfig support.
For this reason, we cannot state in the Barebox, Linux or U-Boot packages whether they support olddefconfig or not, as it depends on the version. By having an automatic handling, regardless of the package and its version, we will use olddefconfig if available, and fallback to the old method if not.
Thanks,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/2 core/pkg-kconfig: add an option to use olddefconfig
2016-03-26 18:52 GMT+01:00 Thomas Petazzoni
<[email protected]>:
Quoted 26 lines
Hello,
Quoted 6 lines · Yann E. MORIN
In fact, we've already discussed this, and we concluded that we would want an automatic behaviour.
I.e. we try to use olddefconfig, and fallback to the yes-trick, like so:
Quoted 7 lines
make olddefconfig || { yes "" |make oldconfig; }Care to adapt your patch and respin, please? Of course, your second patch will no longer make sense after that.
In the meantime, I marked your patches as "Changes Requested" in patchwork.
And here is the reason why we want this automatic behavior rather than the explicit
FOO_KCONFIG_OLDDEFCONFIGvariable that you proposed
Romain: the Linux, Barebox and U-Boot packages, which are some of the main users of kconfig-package infrastructure, have user-configurable versions. Therefore, we don't know if the user will select a recent enough version of the kernel, Barebox or U-Boot with olddefconfig support.
Quoted 5 lines
For this reason, we cannot state in the Barebox, Linux or U-Boot packages whether they support olddefconfig or not, as it depends on the version. By having an automatic handling, regardless of the package and its version, we will use olddefconfig if available, and fallback to the old method if not.
If we want to handle not only the existing case, but also the historic cases, we have to use the 'oldnoconfig' target name, as the kernel target was only available under this name between versions 2.6.36 and 3.6. It is still supported, even if it is a misnomer.
I will update the patch to handle this.
Best regards,
Signature · 1 line
Romain Izard