BMC/Intel-BMC/linux.git/scripts/kconfig/lkc.h, branch dev-4.17

kconfig: use yylineno option instead of manual lineno increments

2018-03-25T17:04:07+00:00

Tracking the line number by hand is error-prone since you need to increment it in every \n matching pattern. If '%option yylineno' is set, flex defines 'yylineno' to contain the current line number and automatically updates it each time it reads a \n character. This is much more convenient although the lexer does not initializes yylineno, so you need to set it to 1 each time you start reading a new file, and restore it you go back to the previous file. I tested this with DEBUG_PARSE, and confirmed the same dump message was produced. I removed the perf-report option. Otherwise, I see the following message: %option yylineno entails a performance penalty ONLY on rules that can match newline characters Signed-off-by: Masahiro Yamada

kconfig: add xstrdup() helper

2018-03-01T15:26:47+00:00

We already have xmalloc(), xcalloc(), and xrealloc((). Add xstrdup() as well to save tedious error handling. Signed-off-by: Masahiro Yamada

kconfig: add xrealloc() helper

2018-02-10T02:26:04+00:00

We already have xmalloc(), xcalloc(). Add xrealloc() as well to save tedious error handling. Signed-off-by: Masahiro Yamada

kconfig: Remove menu_end_entry()

2018-01-21T15:49:28+00:00

menu_end_entry() is empty and completely unused as far as I can tell: $ git log -G menu_end_entry --oneline a02f057 [PATCH] kconfig: improve error handling in the parser 1da177e Linux-2.6.12-rc2 Last one is the initial Git commit, where menu_end_entry() is empty as well. I couldn't find anything that redefined it on Google either. It might be a debugging helper for setting a breakpoint after each config, menuconfig, and comment is parsed. IMO it hurts more than it helps in that case by making the parsing code look more complicated at a glance than it really is, and I suspect it doesn't get used much. Tested by running the Kconfiglib test suite, which indirectly verifies that the .config files generated by the C implementation for each defconfig file in the kernel stays the same. Signed-off-by: Ulf Magnusson Signed-off-by: Masahiro Yamada

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"