kernel/linux.git/scripts/kconfig/lkc.h, branch v4.14.78

Remove gperf usage from toolchain

2017-08-19T18:02:53+00:00

It turns out that gperf-3.1 changed types in the generated code in ways that aren't even trivially detectable without having to generate a test-file. It's just not worth using tools and libraries from clowns that don't understand or care about compatibility. So get rid of gperf. Signed-off-by: Linus Torvalds

kconfig: Remove unnecessary prototypes from headers

2015-02-25T14:00:17+00:00

Signed-off-by: Michal Marek

kconfig: Remove dead code

2015-02-25T14:00:16+00:00

Signed-off-by: Michal Marek

kconfig: Get rid of the P() macro in headers

2015-02-25T14:00:16+00:00

This was originally meant for dlopen()ing a potential kconfig shared library. The unused dlopen code has already been removed in commit 5a6f8d2b (kconfig: nuke LKC_DIRECT_LINK cruft), so let's remove the rest. The lkc_proto.h change was made with the following sed script: sed -r 's/^P$([^,]*), *([^,]*), *(.*)$;/\2 \1\3;/' Plus some manual adjustments. Signed-off-by: Michal Marek

kconfig: make allnoconfig disable options behind EMBEDDED and EXPERT

2014-04-07T23:36:09+00:00

"make allnoconfig" exists to ease testing of minimal configurations. Documentation/SubmitChecklist includes a note to test with allnoconfig. This helps catch missing dependencies on common-but-not-required functionality, which might otherwise go unnoticed. However, allnoconfig still leaves many symbols enabled, because they're hidden behind CONFIG_EMBEDDED or CONFIG_EXPERT. For instance, allnoconfig still has CONFIG_PRINTK and CONFIG_BLOCK enabled, so drivers don't typically get build-tested with those disabled. To address this, introduce a new Kconfig option "allnoconfig_y", used on symbols which only exist to hide other symbols. Set it on CONFIG_EMBEDDED (which then selects CONFIG_EXPERT). allnoconfig will then disable all the symbols hidden behind those. Signed-off-by: Josh Triplett Tested-by: Paul E. McKenney Cc: Michal Marek Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

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

2013-06-24T18:03:30+00:00

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: Fix defconfig when one choice menu selects options that another choice menu depends on

2013-06-16T09:00:30+00:00

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

kconfig: Fix malloc handling in conf tools

2012-11-20T11:12:47+00:00

(and get them out of the noise in the audit work) Signed-off-by: Alan Cox Signed-off-by: Michal Marek

kconfig: get CONFIG_ prefix from the environment

2012-11-20T10:20:08+00:00

Currently, the CONFIG_ prefix is hard-coded in the kconfig frontends executables. This means that two projects that use kconfig with different prefixes can not share the same kconfig frontends. Instead of hard-coding the prefix in the frontends, get it from the environment, and revert back to hard-coded value if not found. Signed-off-by: "Yann E. MORIN" Signed-off-by: Michal Marek

kconfig: add a function to get the CONFIG_ prefix

2012-11-20T10:20:08+00:00

Currently, we get the CONFIG_ prefix via the CONFIG_ macro, which means the CONFIG_ prefix is hard-coded at compile time. This goes against having a run-time defined CONFIG_ prefix. Add a function that returns the CONFIG_ prefix to use (but keep the current hard-coded behavior, to be changed in a later patch). To avoid touching all the code that uses the CONFIG_ macro, we just undef it, and define it to be a call to the function. Signed-off-by: "Yann E. MORIN" Signed-off-by: Michal Marek