linux/scripts/kconfig/confdata.c, branch v3.11

Revert "kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG"

2013-06-26T13:49:00Z

This reverts commit 8357b48549e17b3e4e402c7f977b65708922e60f. It breaks more stuff than it fixes. Reported-by: Fengguang Wu Reported-by: Sedat Dilek Signed-off-by: "Yann E. MORIN" Cc: Fengguang Wu Cc: Sedat Dilek Cc: Sam Ravnborg Cc: Stephen Rothwell Cc: Alexandre Bounine Cc: Matt Porter Signed-off-by: Michal Marek

kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG

2013-06-24T18:03:31Z

Currently, randconfig does randomise choice entries, unless KCONFIG_ALLCONFIG is specified. For example, given those two files (Thomas' test-case): ---8<--- Config.test.in config OPTIONA bool "Option A" choice prompt "This is a choice" config CHOICE_OPTIONA bool "Choice Option A" config CHOICE_OPTIONB bool "Choice Option B" endchoice config OPTIONB bool "Option B" ---8<--- Config.test.in ---8<--- config.defaults CONFIG_OPTIONA=y ---8<--- config.defaults And running: ./scripts/kconfig/conf --randconfig Config.test.in does properly randomise the two choice symbols (and the two booleans). However, running: KCONFIG_ALLCONFIG=config.defaults \ ./scripts/kconfig/conf --randconfig Config.test.in does *not* reandomise the two choice entries, and only CHOICE_OPTIONA will ever be selected. (OPTIONA will always be set (expected), and OPTIONB will be be properly randomised (expected).) This patch defers setting that a choice has a value until a symbol for that choice is indeed set, so that choices are properly randomised when KCONFIG_ALLCONFIG is set, but not if a symbol for that choice is set. Reported-by: Thomas Petazzoni Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Cc: Michal Marek Cc: Sam Ravnborg Cc: Sedat Dilek Cc: Arnd Bergmann Cc: Stephen Rothwell --- Changes v3 -> v4 - fix previous issue where some choices would not be set, which would cause silentoldconfig to ask for them and was then breaking this workflow (as reported by Arnd and Sedat): KCONFIG_ALLCONFIG=foo.defconfig make randconfig make silentoldconfig /dev/null 2>&1 make silentoldconfig /dev/null 2>&1 || break done which did not break at all. - change done in v3 (below) is already fixed by a previous patch Changes v2 -> v3 - ensure only one symbol is set in a choice Changes v1 -> v2: - further postpone setting that a choice has a value until one is indeed set - do not print symbols that are part of an invisible choice

kconfig: loop as long as we changed some symbols in randconfig

2013-06-24T18:03:30Z

Because of choice-in-a-choice constructs, it can happen that not all symbols are assigned a value during randconfig, leading in rare cases to this situation: ---8<--- choice-in-choice.in choice bool "A/B/C" config A bool "A" config B bool "B" if B choice bool "E/F" config E bool "E" config F bool "F" endchoice endif # B config C bool "C" endchoice ---8<--- $ ./scripts/kconfig/conf --randconfig choice-in-choice.in [--SNIP--] $ ./scripts/kconfig/conf --silentoldconfig choice-in-choice.in 2. B (B) 3. C (C) choice[1-3]: 2 E/F > 1. E (E) (NEW) 2. F (F) (NEW) choice[1-2]: aborted! Console input/output is redirected. Run 'make oldconfig' to update configuration. Fix this by looping in randconfig for as long as some symbol gets assigned a value. Note: this was spotted with the USB EHCI Debug Device Gadget (USB_G_DBGP), which uses this choice-in-a-choice construct, and exhibits this problem. The example above is just a stripped-down minimalist test-case. Signed-off-by: "Yann E. MORIN"

kconfig/conf: fix randconfig setting multiple symbols in a choice

2013-06-18T21:59:00Z

Currently, randconfig may set more than one symbol in a given choice. Given this config file: config A bool "A" if A choice bool "B/C/D" config B bool "B" config C bool "C" config D bool "D" endchoice endif # A Then randconfig generates such .config files (case where A is not set is not shown below for brevity), and where only the right-most .config is valid: CONFIG_A=y CONFIG_A=y CONFIG_A=y CONFIG_B=y CONFIG_B=y CONFIG_B=y CONFIG_C=y # CONFIG_C is not set # CONFIG_C is not set # CONFIG_D is not set CONFIG_D=y # CONFIG_D is not set That is, in a randomised choice, the first symbol is always selected, and at most one other symbol may be selected. This is due to symbol randomised in a choice not being properly flagged as having a value. Fix that by flagging those symbols adequately: have a user-defined value, and be not valid (to force recalculation of the symbol). Note: if the choice is not conditional, then the randomisation is properly done. Reported-by: Matthieu CASTET Signed-off-by: Matthieu CASTET [yann.morin.1998@free.fr: independently re-done the same patch as Matthieu, as pointed out by Sedat] Cc: Arnaud Lacombe Cc: Sedat Dilek Signed-off-by: "Yann E. MORIN"

kconfig: Fix defconfig when one choice menu selects options that another choice menu depends on

2013-06-16T09:00:30Z

The defconfig and Kconfig combination below, which is based on 3.10-rc4 Kconfigs, resulted in several options getting set to "m" instead of "y". defconfig.choice: ---8<--- CONFIG_MODULES=y CONFIG_USB_ZERO=y ---8<--- Kconfig.choice: ---8<--- menuconfig MODULES bool "Enable loadable module support" config CONFIGFS_FS tristate "Userspace-driven configuration filesystem" config OCFS2_FS tristate "OCFS2 file system support" depends on CONFIGFS_FS select CRC32 config USB_LIBCOMPOSITE tristate select CONFIGFS_FS choice tristate "USB Gadget Drivers" default USB_ETH config USB_ZERO tristate "Gadget Zero (DEVELOPMENT)" select USB_LIBCOMPOSITE config USB_ETH tristate "Ethernet Gadget (with CDC Ethernet support)" select USB_LIBCOMPOSITE endchoice config CRC32 tristate "CRC32/CRC32c functions" default y choice prompt "CRC32 implementation" depends on CRC32 default CRC32_SLICEBY8 config CRC32_SLICEBY8 bool "Slice by 8 bytes" endchoice ---8<--- $ scripts/kconfig/conf --defconfig=defconfig.choice Kconfig.choice would result in: .config: ---8<--- CONFIG_MODULES=y CONFIG_CONFIGFS_FS=m CONFIG_USB_LIBCOMPOSITE=m CONFIG_USB_ZERO=m CONFIG_CRC32=y CONFIG_CRC32_SLICEBY8=y ---8<--- when the expected result would be: .config: ---8<--- CONFIG_MODULES=y CONFIG_CONFIGFS_FS=y CONFIG_USB_LIBCOMPOSITE=y CONFIG_USB_ZERO=y CONFIG_CRC32=y CONFIG_CRC32_SLICEBY8=y ---8<--- Signed-off-by: Arve Hjønnevåg [yann.morin.1998@free.fr: add the resulting .config to commit log, remove unneeded USB_GADGET from the defconfig] Tested-by: "Yann E. MORIN" Reviewed-by: "Yann E. MORIN" Signed-off-by: Yann E. MORIN

Revert "kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG"

2013-04-26T21:21:59Z

This reverts commit 422c809f03f043d0950d8362214818e956a9daee. It causes more harm than it solves issues. Reported-by: Sedat Dilek Reported-by: Arnd Bergmann Signed-off-by: "Yann E. MORIN" Tested-by: Sedat Dilek Cc: Sedat Dilek Cc: Arnd Bergmann Cc: Michal Marek Cc: Sam Ravnborg Cc: Stephen Rothwell Cc: Thomas Petazzoni Cc: Greg KH

kconfig: implement KCONFIG_PROBABILITY for randconfig

2013-04-24T22:16:30Z

Currently the odds to set each symbol is (rounded): booleans: y: 50% n: 50% tristates: y: 33% m: 33% n: 33% Introduce a KCONFIG_PROBABILITY environment variable to tweak the probabilities (in percentage), as such: KCONFIG_PROBABILITY y:n split y:m:n split ----------------------------------------------------------------- [1] unset or empty 50 : 50 33 : 33 : 34 [2] N N : 100-N N/2 : N/2 : 100-N N:M N+M : 100-(N+M) N : M : 100-(N+M) N:M:L N : 100-N M : L : 100-(M+L) [1] The current behaviour is kept as default, for backward compatibility [2] The solution initially implemented by Peter for Buildroot, see: http://git.buildroot.org/buildroot/commit/?id=3435c1afb5 Signed-off-by: Peter Korsgaard [yann.morin.1998@free.fr: add to Documentation/] Signed-off-by: "Yann E. MORIN"

kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG

2013-04-24T22:16:12Z

Currently, randconfig does randomise choice entries, unless KCONFIG_ALLCONFIG is specified. For example, given those two files (Thomas' test-case): ---8<--- Config.test.in config OPTIONA bool "Option A" choice prompt "This is a choice" config CHOICE_OPTIONA bool "Choice Option A" config CHOICE_OPTIONB bool "Choice Option B" endchoice config OPTIONB bool "Option B" ---8<--- Config.test.in ---8<--- config.defaults CONFIG_OPTIONA=y ---8<--- config.defaults And running: ./scripts/kconfig/conf --randconfig Config.test.in does properly randomise the two choice symbols (and the two booleans). However, running: KCONFIG_ALLCONFIG=config.defaults \ ./scripts/kconfig/conf --randconfig Config.test.in does *not* reandomise the two choice entries, and only CHOICE_OPTIONA will ever be selected. (OPTIONA will always be set (expected), and OPTIONB will be be properly randomised (expected).) This patch defers setting that a choice has a value until a symbol for that choice is indeed set, so that choices are properly randomised when KCONFIG_ALLCONFIG is set, but not if a symbol for that choice is set. Also, as a side-efect, this patch fixes the following case: ---8<--- choice config OPTION_A bool "Option A" config OPTION_B bool "Option B" config OPTION_C bool "Option C" endchoice ---8<--- which could previously generate such .config files: ---8<--- ---8<--- CONFIG_OPTION_A=y CONFIG_OPTION_A=y CONFIG_OPTION_B=y # CONFIG_OPTION_B is not set # CONFIG_OPTION_C is not set CONFIG_OPTION_C=y ---8<--- ---8<--- Ie., the first entry in a choice is always set, plus zero or one of the other options may be set. This patch ensures that only one option may be set for a choice. Reported-by: Thomas Petazzoni Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Cc: Michal Marek Cc: Sam Ravnborg Cc: Arnaud Lacombe --- Changes v2 -> v3 - ensure only one symbol is set in a choice Changes v1 -> v2: - further postpone setting that a choice has a value until one is indeed set - do not print symbols that are part of an invisible choice

kconfig: do not override symbols already set

2013-04-24T22:15:58Z

For randconfig, if a list of required symbols is specified with KCONFIG_ALLCONFIG, such symbols do not "have a value" as per sym_has_value(), but have the "valid" flag set. Signed-off-by: "Yann E. MORIN"

kconfig: fix randconfig tristate detection

2013-04-24T22:15:47Z

Because the modules' symbole (CONFIG_MODULES) may not yet be set when we check a symbol's tristate capabilty, we'll always find that tristate symbols are booleans, even if we randomly decided that to enable modules: sym_get_type(sym) always return boolean for tristates when modules_sym has not been previously set to 'y' *and* its value calculated *and* its visibility calculated, both of which only occur after we randomly assign values to symbols. Fix that by looking at the raw type of symbols. Tristate set to 'm' will be promoted to 'y' when their values will be later calculated. Signed-off-by: "Yann E. MORIN"