Skip to contentSkip to conversation

core/pkg-kconfig: add an option to use olddefconfig

PATCH New Romain Izard 3 participants 5 messages Mar 25, 2016 – Mar 29, 2016

lore
Share & tools
lore
#0 lore raw

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
index 3290024..50c4ecb 100644
@@ -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
index 90f3f9f..71c6865 100644
@@ -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
#1 lore raw

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
index 7e20255..7e3d5f8 100644
@@ -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
#2 lore raw

PATCH 1/2 core/pkg-kconfig: add an option to use olddefconfig

In reply to Romain Izard

Romain, 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
---
 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
index 3290024..50c4ecb 100644
@@ -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
index 90f3f9f..71c6865 100644
@@ -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 · 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.  |
'------------------------------^-------^------------------^--------------------'
#3 lore raw

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
#4 lore raw

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_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.

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