kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-09-28 19:20:30 +00:00
Code Issues Releases Packages Activity
linux/scripts/kconfig/parser.y

716 lines
15 KiB
Raw Permalink Normal View History

kconfig: convert to SPDX License Identifier All files in lxdialog/ are licensed under GPL-2.0+, and the rest are under GPL-2.0. I added GPL-2.0 tags to test scripts in tests/. Documentation/process/license-rules.rst does not suggest anything about the flex/bison files. Because flex does not accept the C++ comment style at the very top of a file, I used the C style for zconf.l, and so for zconf.y for consistency. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-18 21:13:35 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: convert to SPDX License Identifier All files in lxdialog/ are licensed under GPL-2.0+, and the rest are under GPL-2.0. I added GPL-2.0 tags to test scripts in tests/. Documentation/process/license-rules.rst does not suggest anything about the flex/bison files. Because flex does not accept the C++ comment style at the very top of a file, I used the C style for zconf.l, and so for zconf.y for consistency. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-18 21:13:35 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] kconfig: use gperf for kconfig keywords Use gperf to generate a hash for the kconfig keywords. This greatly reduces the size of the generated scanner and makes it easier to extend kconfig. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:51 -08:00
kconfig: split menu.c out of parser.y Compile menu.c as an independent compilation unit. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-04-14 00:08:17 +09:00
[PATCH] kconfig: use gperf for kconfig keywords Use gperf to generate a hash for the kconfig keywords. This greatly reduces the size of the generated scanner and makes it easier to extend kconfig. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:51 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: use default 'yy' prefix for lexer and parser Flex and Bison provide an option to change the prefix of globally- visible symbols. This is useful to link multiple lexers and/or parsers into the same executable. However, Kconfig (and any other host programs in kernel) uses a single lexer and parser. I do not see a good reason to change the default 'yy' prefix. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-01-12 00:50:50 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
kconfig: refactor end token rules T_ENDMENU, T_ENDCHOICE, T_ENDIF are the last users of kconf_id associated with yylval. Refactor them to not use it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:06 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
Improve kconfig symbol hashing While looking for something else I noticed that the symbol hash function used by kconfig is quite poor. It doesn't use any of the standard hash techniques but simply adds up the string and then uses power of two masking, which is both known to perform poorly. The current x86 kconfig has over 7000 symbols. When I instrumented it showed that the minimum hash chain length was 16 and a significant number of them was over 30. It didn't help that the hash table size was only 256 buckets. This patch increases the hash table size to a larger prime and switches to a FNV32 hash. I played around with a couple of hash functions, but that one seemed to perform best with reasonable hash table sizes. Increasing the hash table size even further didn't seem like a good idea, because there are a couple of global walks which walk the complete hash table. I also moved the unnamed bucket to 0. It's still the longest of all the buckets (44 entries), but hopefully it's not often hit except for the global walk which doesn't care. The result is a much nicer distribution: (first column bucket length, second number of buckets with that length) 1: 3505 2: 1236 3: 294 4: 52 5: 3 47: 1 <--- this is the unnamed symbols bucket There are still some 5+ buckets, but increasing the hash table even more would be likely not worth it. This also cleans up the code slightly by removing hard coded magic numbers. I didn't notice a big performance difference either way on my Nehalem system, but I presume it'll help somewhat on slower systems. Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-01-13 17:02:44 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: split menu.c out of parser.y Compile menu.c as an independent compilation unit. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-04-14 00:08:17 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: use distinct tokens for type and default properties This commit removes kconf_id::stype to prepare for the entire removal of kconf_id.c To simplify the lexer, I want keywords straight-mapped to tokens. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:59 +09:00
kconfig: support simply expanded variable The previous commit added variable and user-defined function. They work similarly in the sense that the evaluation is deferred until they are used. This commit adds another type of variable, simply expanded variable, as we see in Make. The := operator defines a simply expanded variable, expanding the righthand side immediately. This works like traditional programming language variables. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-05-28 18:21:50 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: use distinct tokens for type and default properties This commit removes kconf_id::stype to prepare for the entire removal of kconf_id.c To simplify the lexer, I want keywords straight-mapped to tokens. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:59 +09:00
kconfig: stop associating kconf_id with yylval The lexer has conventionally associated kconf_id data with yylval to carry additional information to the parser. No token is relying on this any more. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:07 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: use specific tokens instead of T_ASSIGN for assignments Currently, the lexer returns T_ASSIGN for all of =, :=, and += associating yylval with the flavor. I want to make the generated lexer as simple as possible. So, the lexer should convert keywords to tokens without thinking about the meaning. = -> T_EQUAL := -> T_COLON_EQUAL += -> T_PLUS_EQUAL Unfortunately, Kconfig uses = instead of == for the equal operator. So, the same token T_EQUAL is used for assignment and comparison. The parser can still distinguish them from the context. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:01 +09:00
kconfig: stop associating kconf_id with yylval The lexer has conventionally associated kconf_id data with yylval to carry additional information to the parser. No token is relying on this any more. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:07 +09:00
kconfig: use distinct tokens for type and default properties This commit removes kconf_id::stype to prepare for the entire removal of kconf_id.c To simplify the lexer, I want keywords straight-mapped to tokens. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:59 +09:00
kconfig: stop associating kconf_id with yylval The lexer has conventionally associated kconf_id data with yylval to carry additional information to the parser. No token is relying on this any more. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:07 +09:00
kconfig: use distinct tokens for type and default properties This commit removes kconf_id::stype to prepare for the entire removal of kconf_id.c To simplify the lexer, I want keywords straight-mapped to tokens. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:59 +09:00
kconfig: stop associating kconf_id with yylval The lexer has conventionally associated kconf_id data with yylval to carry additional information to the parser. No token is relying on this any more. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:07 +09:00
kconfig: use distinct tokens for type and default properties This commit removes kconf_id::stype to prepare for the entire removal of kconf_id.c To simplify the lexer, I want keywords straight-mapped to tokens. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:59 +09:00
kconfig: stop associating kconf_id with yylval The lexer has conventionally associated kconf_id data with yylval to carry additional information to the parser. No token is relying on this any more. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:07 +09:00
kconfig: refactor scanning and parsing "option" properties For the keywords "modules", "defconfig_list", and "allnoconfig_y", the lexer should pass specific tokens instead of generic T_WORD. This simplifies both the lexer and the parser. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:00 +09:00
kconfig: stop associating kconf_id with yylval The lexer has conventionally associated kconf_id data with yylval to carry additional information to the parser. No token is relying on this any more. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:07 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: stop associating kconf_id with yylval The lexer has conventionally associated kconf_id data with yylval to carry additional information to the parser. No token is relying on this any more. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:07 +09:00
kconfig: use specific tokens instead of T_ASSIGN for assignments Currently, the lexer returns T_ASSIGN for all of =, :=, and += associating yylval with the flavor. I want to make the generated lexer as simple as possible. So, the lexer should convert keywords to tokens without thinking about the meaning. = -> T_EQUAL := -> T_COLON_EQUAL += -> T_PLUS_EQUAL Unfortunately, Kconfig uses = instead of == for the equal operator. So, the same token T_EQUAL is used for assignment and comparison. The parser can still distinguish them from the context. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:01 +09:00
kconfig: stop associating kconf_id with yylval The lexer has conventionally associated kconf_id data with yylval to carry additional information to the parser. No token is relying on this any more. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:07 +09:00
kconfig: use distinct tokens for type and default properties This commit removes kconf_id::stype to prepare for the entire removal of kconf_id.c To simplify the lexer, I want keywords straight-mapped to tokens. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:59 +09:00
kconfig: stop associating kconf_id with yylval The lexer has conventionally associated kconf_id data with yylval to carry additional information to the parser. No token is relying on this any more. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:07 +09:00
[PATCH] kconfig: simplify symbol type parsing This simplifies the parser a bit by merging the various symbol types into a single token and adds the type to the keyword hash. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:52 -08:00
kconfig: support user-defined function and recursively expanded variable Now, we got a basic ability to test compiler capability in Kconfig. config CC_HAS_STACKPROTECTOR def_bool $(shell,($(CC) -Werror -fstack-protector -E -x c /dev/null -o /dev/null 2>/dev/null) && echo y || echo n) This works, but it is ugly to repeat this long boilerplate. We want to describe like this: config CC_HAS_STACKPROTECTOR bool default $(cc-option,-fstack-protector) It is straight-forward to add a new function, but I do not like to hard-code specialized functions like that. Hence, here is another feature, user-defined function. This works as a textual shorthand with parameterization. A user-defined function is defined by using the = operator, and can be referenced in the same way as built-in functions. A user-defined function in Make is referenced like $(call my-func,arg1,arg2), but I omitted the 'call' to make the syntax shorter. The definition of a user-defined function contains $(1), $(2), etc. in its body to reference the parameters. It is grammatically valid to pass more or fewer arguments when calling it. We already exploit this feature in our makefiles; scripts/Kbuild.include defines cc-option which takes two arguments at most, but most of the callers pass only one argument. By the way, a variable is supported as a subset of this feature since a variable is "a user-defined function with zero argument". In this context, I mean "variable" as recursively expanded variable. I will add a different flavored variable in the next commit. The code above can be written as follows: [Example Code] success = $(shell,($(1)) >/dev/null 2>&1 && echo y || echo n) cc-option = $(success,$(CC) -Werror $(1) -E -x c /dev/null -o /dev/null) config CC_HAS_STACKPROTECTOR def_bool $(cc-option,-fstack-protector) [Result] $ make -s alldefconfig && tail -n 1 .config CONFIG_CC_HAS_STACKPROTECTOR=y Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-05-28 18:21:49 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: allow use of relations other than (in)equality Over the years I found it desirable to be able to use all sorts of relations, not just (in)equality. And apparently I'm not the only one, as there's at least one example in the tree where the programmer assumed this would work (see DEBUG_UART_8250_WORD in arch/arm/Kconfig.debug). Another possible use would e.g. be to fold the two SMP/NR_CPUS prompts into one: SMP could be promptless, simply depending on NR_CPUS > 1. A (desirable) side effect of this change - resulting from numeric values now necessarily being compared as numbers rather than as strings - is that comparing hex values now works as expected: Other than int ones (which aren't allowed to have leading zeroes), zeroes following the 0x prefix made them compare unequal even if their values were equal. Signed-off-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2015-06-15 13:00:21 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: Don't leak symbol names during parsing Prior to this fix, zconf.y did not free symbol names from zconf.l in these contexts: - After T_CONFIG ('config LEAKED') - After T_MENUCONFIG ('menuconfig LEAKED') - After T_SELECT ('select LEAKED') - After T_IMPLY ('imply LEAKED') - After T_DEFAULT in a choice ('default LEAKED') All of these come in the form of T_WORD tokens, which always have their associated string allocated on the heap in zconf.l and need to be freed. Fix by introducing a new nonterminal 'nonconst_symbol' which takes a T_WORD, fetches the symbol, and then frees the T_WORD string. The already existing 'symbol' nonterminal works the same way but also accepts T_WORD_QUOTE, corresponding to a constant symbol. T_WORD_QUOTE should not be accepted in any of the contexts above, so the 'symbol' nonterminal can't be reused here. Fetching the symbol in 'nonconst_symbol' also removes a bunch of sym_lookup() calls from actions. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 711,571 bytes in 37,756 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 387,504 bytes in 15,545 blocks ... Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-08 19:11:18 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: use distinct tokens for type and default properties This commit removes kconf_id::stype to prepare for the entire removal of kconf_id.c To simplify the lexer, I want keywords straight-mapped to tokens. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:59 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: refactor end token rules T_ENDMENU, T_ENDCHOICE, T_ENDIF are the last users of kconf_id associated with yylval. Refactor them to not use it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:06 +09:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
kconfig: refactor scanning and parsing "option" properties For the keywords "modules", "defconfig_list", and "allnoconfig_y", the lexer should pass specific tokens instead of generic T_WORD. This simplifies both the lexer and the parser. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:00 +09:00
kconfig: use specific tokens instead of T_ASSIGN for assignments Currently, the lexer returns T_ASSIGN for all of =, :=, and += associating yylval with the flavor. I want to make the generated lexer as simple as possible. So, the lexer should convert keywords to tokens without thinking about the meaning. = -> T_EQUAL := -> T_COLON_EQUAL += -> T_PLUS_EQUAL Unfortunately, Kconfig uses = instead of == for the equal operator. So, the same token T_EQUAL is used for assignment and comparison. The parser can still distinguish them from the context. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:01 +09:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: fix ambiguous grammar in terms of new lines This commit decreases 8 shift/reduce conflicts. A certain amount of grammatical ambiguity comes from how to reduce excessive T_EOL tokens. Let's take a look at the example code below: 1 config A 2 bool "a" 3 4 depends on B 5 6 config B 7 def_bool y The line 3 is melt into "config_option_list", but the line 5 can be either a part of "config_option_list" or "common_stmt" by itself. Currently, the lexer converts '\n' to T_EOL verbatim. In Kconfig, a new line works as a statement terminator, but new lines in empty lines are not critical since empty lines (or lines that contain only whitespaces/comments) are just no-op. If the lexer simply discards no-op lines, the parser will not be bothered by excessive T_EOL tokens. Of course, this means we are shifting the complexity from the parser to the lexer, but it is much easier than tackling on shift/reduce conflicts. I introduced the second stage lexer to tweak the behavior. Discard T_EOL if the previous token is T_EOL or T_HELPTEXT. Two T_EOL tokens in a row is meaningless. T_HELPTEXT is a special token that is reduced without T_EOL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:49 +09:00
kconfig: Don't leak main menus during parsing If a 'mainmenu' entry appeared in the Kconfig files, two things would leak: - The 'struct property' allocated for the default "Linux Kernel Configuration" prompt. - The string for the T_WORD/T_WORD_QUOTE prompt after the T_MAINMENU token, allocated on the heap in zconf.l. To fix it, introduce a new 'no_mainmenu_stmt' nonterminal that matches if there's no 'mainmenu' and adds the default prompt. That means the prompt only gets allocated once regardless of whether there's a 'mainmenu' statement or not, and managing it becomes simple. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 344,568 bytes in 14,352 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 344,440 bytes in 14,350 blocks ... Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-08 19:11:21 +02:00
kconfig: remove 'prompt' symbol Now that 'prompt' is only reduced from T_WORD_QUOTE without any action, use T_WORD_QUOTE directly. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2019-12-17 13:14:19 +09:00
kconfig: Don't leak main menus during parsing If a 'mainmenu' entry appeared in the Kconfig files, two things would leak: - The 'struct property' allocated for the default "Linux Kernel Configuration" prompt. - The string for the T_WORD/T_WORD_QUOTE prompt after the T_MAINMENU token, allocated on the heap in zconf.l. To fix it, introduce a new 'no_mainmenu_stmt' nonterminal that matches if there's no 'mainmenu' and adds the default prompt. That means the prompt only gets allocated once regardless of whether there's a 'mainmenu' statement or not, and managing it becomes simple. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 344,568 bytes in 14,352 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 344,440 bytes in 14,350 blocks ... Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-08 19:11:21 +02:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
kconfig: allow only 'config', 'comment', and 'if' inside 'choice' The code block surrounded by 'if' ... 'endif' is reduced into if_stmt, which is accepted in the 'choice' context. Therefore, you can write any statements within a choice block by wrapping 'if y' ... 'end'. For example, you can create a menu inside a choice, like follows: ---------------->8---------------- choice prompt "choice" config A bool "A" config B bool "B" if y menu "strange menu" config C bool "C" endmenu endif endchoice ---------------->8---------------- I want to change such a weird structure into a syntax error. In fact, the USB gadget Kconfig had used nested 'choice' for no good reason until commit df8df5e4bc37 ("usb: get rid of 'choice' for legacy gadget drivers") killed it. I think the 'source' inside 'choice' is on the fence. It is at least gramatically sensible as long as the included file contains only bool/tristate configs. However, it makes the code unreadable, and people tend to forget the fact that the file is included from the choice block. Commit 10e5e6c24963 ("usb: gadget: move choice ... endchoice to legacy/Kconfig") got rid of the only usecase. Going forward, you can only use 'config', 'comment', and 'if' inside 'choice'. This also recursively applies to 'if' blocks inside 'choice'. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-24 14:49:29 +09:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
kconfig: allow only 'config', 'comment', and 'if' inside 'choice' The code block surrounded by 'if' ... 'endif' is reduced into if_stmt, which is accepted in the 'choice' context. Therefore, you can write any statements within a choice block by wrapping 'if y' ... 'end'. For example, you can create a menu inside a choice, like follows: ---------------->8---------------- choice prompt "choice" config A bool "A" config B bool "B" if y menu "strange menu" config C bool "C" endmenu endif endchoice ---------------->8---------------- I want to change such a weird structure into a syntax error. In fact, the USB gadget Kconfig had used nested 'choice' for no good reason until commit df8df5e4bc37 ("usb: get rid of 'choice' for legacy gadget drivers") killed it. I think the 'source' inside 'choice' is on the fence. It is at least gramatically sensible as long as the included file contains only bool/tristate configs. However, it makes the code unreadable, and people tend to forget the fact that the file is included from the choice block. Commit 10e5e6c24963 ("usb: gadget: move choice ... endchoice to legacy/Kconfig") got rid of the only usecase. Going forward, you can only use 'config', 'comment', and 'if' inside 'choice'. This also recursively applies to 'if' blocks inside 'choice'. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-24 14:49:29 +09:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
kconfig: allow only 'config', 'comment', and 'if' inside 'choice' The code block surrounded by 'if' ... 'endif' is reduced into if_stmt, which is accepted in the 'choice' context. Therefore, you can write any statements within a choice block by wrapping 'if y' ... 'end'. For example, you can create a menu inside a choice, like follows: ---------------->8---------------- choice prompt "choice" config A bool "A" config B bool "B" if y menu "strange menu" config C bool "C" endmenu endif endchoice ---------------->8---------------- I want to change such a weird structure into a syntax error. In fact, the USB gadget Kconfig had used nested 'choice' for no good reason until commit df8df5e4bc37 ("usb: get rid of 'choice' for legacy gadget drivers") killed it. I think the 'source' inside 'choice' is on the fence. It is at least gramatically sensible as long as the included file contains only bool/tristate configs. However, it makes the code unreadable, and people tend to forget the fact that the file is included from the choice block. Commit 10e5e6c24963 ("usb: gadget: move choice ... endchoice to legacy/Kconfig") got rid of the only usecase. Going forward, you can only use 'config', 'comment', and 'if' inside 'choice'. This also recursively applies to 'if' blocks inside 'choice'. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-24 14:49:29 +09:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: allow only 'config', 'comment', and 'if' inside 'choice' The code block surrounded by 'if' ... 'endif' is reduced into if_stmt, which is accepted in the 'choice' context. Therefore, you can write any statements within a choice block by wrapping 'if y' ... 'end'. For example, you can create a menu inside a choice, like follows: ---------------->8---------------- choice prompt "choice" config A bool "A" config B bool "B" if y menu "strange menu" config C bool "C" endmenu endif endchoice ---------------->8---------------- I want to change such a weird structure into a syntax error. In fact, the USB gadget Kconfig had used nested 'choice' for no good reason until commit df8df5e4bc37 ("usb: get rid of 'choice' for legacy gadget drivers") killed it. I think the 'source' inside 'choice' is on the fence. It is at least gramatically sensible as long as the included file contains only bool/tristate configs. However, it makes the code unreadable, and people tend to forget the fact that the file is included from the choice block. Commit 10e5e6c24963 ("usb: gadget: move choice ... endchoice to legacy/Kconfig") got rid of the only usecase. Going forward, you can only use 'config', 'comment', and 'if' inside 'choice'. This also recursively applies to 'if' blocks inside 'choice'. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-24 14:49:29 +09:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: Don't leak symbol names during parsing Prior to this fix, zconf.y did not free symbol names from zconf.l in these contexts: - After T_CONFIG ('config LEAKED') - After T_MENUCONFIG ('menuconfig LEAKED') - After T_SELECT ('select LEAKED') - After T_IMPLY ('imply LEAKED') - After T_DEFAULT in a choice ('default LEAKED') All of these come in the form of T_WORD tokens, which always have their associated string allocated on the heap in zconf.l and need to be freed. Fix by introducing a new nonterminal 'nonconst_symbol' which takes a T_WORD, fetches the symbol, and then frees the T_WORD string. The already existing 'symbol' nonterminal works the same way but also accepts T_WORD_QUOTE, corresponding to a constant symbol. T_WORD_QUOTE should not be accepted in any of the contexts above, so the 'symbol' nonterminal can't be reused here. Fetching the symbol in 'nonconst_symbol' also removes a bunch of sym_lookup() calls from actions. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 711,571 bytes in 37,756 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 387,504 bytes in 15,545 blocks ... Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-08 19:11:18 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: Don't leak symbol names during parsing Prior to this fix, zconf.y did not free symbol names from zconf.l in these contexts: - After T_CONFIG ('config LEAKED') - After T_MENUCONFIG ('menuconfig LEAKED') - After T_SELECT ('select LEAKED') - After T_IMPLY ('imply LEAKED') - After T_DEFAULT in a choice ('default LEAKED') All of these come in the form of T_WORD tokens, which always have their associated string allocated on the heap in zconf.l and need to be freed. Fix by introducing a new nonterminal 'nonconst_symbol' which takes a T_WORD, fetches the symbol, and then frees the T_WORD string. The already existing 'symbol' nonterminal works the same way but also accepts T_WORD_QUOTE, corresponding to a constant symbol. T_WORD_QUOTE should not be accepted in any of the contexts above, so the 'symbol' nonterminal can't be reused here. Fetching the symbol in 'nonconst_symbol' also removes a bunch of sym_lookup() calls from actions. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 711,571 bytes in 37,756 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 387,504 bytes in 15,545 blocks ... Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-08 19:11:18 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: Don't leak symbol names during parsing Prior to this fix, zconf.y did not free symbol names from zconf.l in these contexts: - After T_CONFIG ('config LEAKED') - After T_MENUCONFIG ('menuconfig LEAKED') - After T_SELECT ('select LEAKED') - After T_IMPLY ('imply LEAKED') - After T_DEFAULT in a choice ('default LEAKED') All of these come in the form of T_WORD tokens, which always have their associated string allocated on the heap in zconf.l and need to be freed. Fix by introducing a new nonterminal 'nonconst_symbol' which takes a T_WORD, fetches the symbol, and then frees the T_WORD string. The already existing 'symbol' nonterminal works the same way but also accepts T_WORD_QUOTE, corresponding to a constant symbol. T_WORD_QUOTE should not be accepted in any of the contexts above, so the 'symbol' nonterminal can't be reused here. Fetching the symbol in 'nonconst_symbol' also removes a bunch of sym_lookup() calls from actions. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 711,571 bytes in 37,756 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 387,504 bytes in 15,545 blocks ... Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-08 19:11:18 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: Don't leak symbol names during parsing Prior to this fix, zconf.y did not free symbol names from zconf.l in these contexts: - After T_CONFIG ('config LEAKED') - After T_MENUCONFIG ('menuconfig LEAKED') - After T_SELECT ('select LEAKED') - After T_IMPLY ('imply LEAKED') - After T_DEFAULT in a choice ('default LEAKED') All of these come in the form of T_WORD tokens, which always have their associated string allocated on the heap in zconf.l and need to be freed. Fix by introducing a new nonterminal 'nonconst_symbol' which takes a T_WORD, fetches the symbol, and then frees the T_WORD string. The already existing 'symbol' nonterminal works the same way but also accepts T_WORD_QUOTE, corresponding to a constant symbol. T_WORD_QUOTE should not be accepted in any of the contexts above, so the 'symbol' nonterminal can't be reused here. Fetching the symbol in 'nonconst_symbol' also removes a bunch of sym_lookup() calls from actions. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 711,571 bytes in 37,756 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 387,504 bytes in 15,545 blocks ... Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-08 19:11:18 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: use distinct tokens for type and default properties This commit removes kconf_id::stype to prepare for the entire removal of kconf_id.c To simplify the lexer, I want keywords straight-mapped to tokens. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:59 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: use distinct tokens for type and default properties This commit removes kconf_id::stype to prepare for the entire removal of kconf_id.c To simplify the lexer, I want keywords straight-mapped to tokens. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:59 +09:00
[PATCH] kconfig: simplify symbol type parsing This simplifies the parser a bit by merging the various symbol types into a single token and adds the type to the keyword hash. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:52 -08:00
kconfig: use distinct tokens for type and default properties This commit removes kconf_id::stype to prepare for the entire removal of kconf_id.c To simplify the lexer, I want keywords straight-mapped to tokens. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:59 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: remove 'prompt' symbol Now that 'prompt' is only reduced from T_WORD_QUOTE without any action, use T_WORD_QUOTE directly. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2019-12-17 13:14:19 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: use distinct tokens for type and default properties This commit removes kconf_id::stype to prepare for the entire removal of kconf_id.c To simplify the lexer, I want keywords straight-mapped to tokens. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:59 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: use distinct tokens for type and default properties This commit removes kconf_id::stype to prepare for the entire removal of kconf_id.c To simplify the lexer, I want keywords straight-mapped to tokens. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:59 +09:00
[PATCH] kconfig: simplify symbol type parsing This simplifies the parser a bit by merging the various symbol types into a single token and adds the type to the keyword hash. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:52 -08:00
kconfig: use distinct tokens for type and default properties This commit removes kconf_id::stype to prepare for the entire removal of kconf_id.c To simplify the lexer, I want keywords straight-mapped to tokens. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:59 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: Don't leak symbol names during parsing Prior to this fix, zconf.y did not free symbol names from zconf.l in these contexts: - After T_CONFIG ('config LEAKED') - After T_MENUCONFIG ('menuconfig LEAKED') - After T_SELECT ('select LEAKED') - After T_IMPLY ('imply LEAKED') - After T_DEFAULT in a choice ('default LEAKED') All of these come in the form of T_WORD tokens, which always have their associated string allocated on the heap in zconf.l and need to be freed. Fix by introducing a new nonterminal 'nonconst_symbol' which takes a T_WORD, fetches the symbol, and then frees the T_WORD string. The already existing 'symbol' nonterminal works the same way but also accepts T_WORD_QUOTE, corresponding to a constant symbol. T_WORD_QUOTE should not be accepted in any of the contexts above, so the 'symbol' nonterminal can't be reused here. Fetching the symbol in 'nonconst_symbol' also removes a bunch of sym_lookup() calls from actions. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 711,571 bytes in 37,756 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 387,504 bytes in 15,545 blocks ... Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-08 19:11:18 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: Don't leak symbol names during parsing Prior to this fix, zconf.y did not free symbol names from zconf.l in these contexts: - After T_CONFIG ('config LEAKED') - After T_MENUCONFIG ('menuconfig LEAKED') - After T_SELECT ('select LEAKED') - After T_IMPLY ('imply LEAKED') - After T_DEFAULT in a choice ('default LEAKED') All of these come in the form of T_WORD tokens, which always have their associated string allocated on the heap in zconf.l and need to be freed. Fix by introducing a new nonterminal 'nonconst_symbol' which takes a T_WORD, fetches the symbol, and then frees the T_WORD string. The already existing 'symbol' nonterminal works the same way but also accepts T_WORD_QUOTE, corresponding to a constant symbol. T_WORD_QUOTE should not be accepted in any of the contexts above, so the 'symbol' nonterminal can't be reused here. Fetching the symbol in 'nonconst_symbol' also removes a bunch of sym_lookup() calls from actions. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 711,571 bytes in 37,756 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 387,504 bytes in 15,545 blocks ... Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-08 19:11:18 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: Don't leak symbol names during parsing Prior to this fix, zconf.y did not free symbol names from zconf.l in these contexts: - After T_CONFIG ('config LEAKED') - After T_MENUCONFIG ('menuconfig LEAKED') - After T_SELECT ('select LEAKED') - After T_IMPLY ('imply LEAKED') - After T_DEFAULT in a choice ('default LEAKED') All of these come in the form of T_WORD tokens, which always have their associated string allocated on the heap in zconf.l and need to be freed. Fix by introducing a new nonterminal 'nonconst_symbol' which takes a T_WORD, fetches the symbol, and then frees the T_WORD string. The already existing 'symbol' nonterminal works the same way but also accepts T_WORD_QUOTE, corresponding to a constant symbol. T_WORD_QUOTE should not be accepted in any of the contexts above, so the 'symbol' nonterminal can't be reused here. Fetching the symbol in 'nonconst_symbol' also removes a bunch of sym_lookup() calls from actions. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 711,571 bytes in 37,756 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 387,504 bytes in 15,545 blocks ... Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-08 19:11:18 +02:00
Kconfig: Introduce the "imply" keyword The "imply" keyword is a weak version of "select" where the target config symbol can still be turned off, avoiding those pitfalls that come with the "select" keyword. This is useful e.g. with multiple drivers that want to indicate their ability to hook into a secondary subsystem while allowing the user to configure that subsystem out without also having to unset these drivers. Currently, the same effect can almost be achieved with: config DRIVER_A tristate config DRIVER_B tristate config DRIVER_C tristate config DRIVER_D tristate [...] config SUBSYSTEM_X tristate default DRIVER_A || DRIVER_B || DRIVER_C || DRIVER_D || [...] This is unwieldy to maintain especially with a large number of drivers. Furthermore, there is no easy way to restrict the choice for SUBSYSTEM_X to y or n, excluding m, when some drivers are built-in. The "select" keyword allows for excluding m, but it excludes n as well. Hence this "imply" keyword. The above becomes: config DRIVER_A tristate imply SUBSYSTEM_X config DRIVER_B tristate imply SUBSYSTEM_X [...] config SUBSYSTEM_X tristate This is much cleaner, and way more flexible than "select". SUBSYSTEM_X can still be configured out, and it can be set as a module when none of the drivers are configured in or all of them are modular. Signed-off-by: Nicolas Pitre <nico@linaro.org> Acked-by: Richard Cochran <richardcochran@gmail.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Cc: Paul Bolle <pebolle@tiscali.nl> Cc: linux-kbuild@vger.kernel.org Cc: netdev@vger.kernel.org Cc: Michal Marek <mmarek@suse.com> Cc: Edward Cree <ecree@solarflare.com> Link: http://lkml.kernel.org/r/1478841010-28605-2-git-send-email-nicolas.pitre@linaro.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2016-11-11 00:10:05 -05:00
kconfig: Don't leak symbol names during parsing Prior to this fix, zconf.y did not free symbol names from zconf.l in these contexts: - After T_CONFIG ('config LEAKED') - After T_MENUCONFIG ('menuconfig LEAKED') - After T_SELECT ('select LEAKED') - After T_IMPLY ('imply LEAKED') - After T_DEFAULT in a choice ('default LEAKED') All of these come in the form of T_WORD tokens, which always have their associated string allocated on the heap in zconf.l and need to be freed. Fix by introducing a new nonterminal 'nonconst_symbol' which takes a T_WORD, fetches the symbol, and then frees the T_WORD string. The already existing 'symbol' nonterminal works the same way but also accepts T_WORD_QUOTE, corresponding to a constant symbol. T_WORD_QUOTE should not be accepted in any of the contexts above, so the 'symbol' nonterminal can't be reused here. Fetching the symbol in 'nonconst_symbol' also removes a bunch of sym_lookup() calls from actions. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 711,571 bytes in 37,756 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 387,504 bytes in 15,545 blocks ... Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-08 19:11:18 +02:00
Kconfig: Introduce the "imply" keyword The "imply" keyword is a weak version of "select" where the target config symbol can still be turned off, avoiding those pitfalls that come with the "select" keyword. This is useful e.g. with multiple drivers that want to indicate their ability to hook into a secondary subsystem while allowing the user to configure that subsystem out without also having to unset these drivers. Currently, the same effect can almost be achieved with: config DRIVER_A tristate config DRIVER_B tristate config DRIVER_C tristate config DRIVER_D tristate [...] config SUBSYSTEM_X tristate default DRIVER_A || DRIVER_B || DRIVER_C || DRIVER_D || [...] This is unwieldy to maintain especially with a large number of drivers. Furthermore, there is no easy way to restrict the choice for SUBSYSTEM_X to y or n, excluding m, when some drivers are built-in. The "select" keyword allows for excluding m, but it excludes n as well. Hence this "imply" keyword. The above becomes: config DRIVER_A tristate imply SUBSYSTEM_X config DRIVER_B tristate imply SUBSYSTEM_X [...] config SUBSYSTEM_X tristate This is much cleaner, and way more flexible than "select". SUBSYSTEM_X can still be configured out, and it can be set as a module when none of the drivers are configured in or all of them are modular. Signed-off-by: Nicolas Pitre <nico@linaro.org> Acked-by: Richard Cochran <richardcochran@gmail.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Cc: Paul Bolle <pebolle@tiscali.nl> Cc: linux-kbuild@vger.kernel.org Cc: netdev@vger.kernel.org Cc: Michal Marek <mmarek@suse.com> Cc: Edward Cree <ecree@solarflare.com> Link: http://lkml.kernel.org/r/1478841010-28605-2-git-send-email-nicolas.pitre@linaro.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2016-11-11 00:10:05 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: change "modules" from sub-option to first-level attribute Now "modules" is the only member of the "option" property. Remove "option", and move "modules" to the top level property. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-03-14 04:48:36 +09:00
kconfig: refactor scanning and parsing "option" properties For the keywords "modules", "defconfig_list", and "allnoconfig_y", the lexer should pass specific tokens instead of generic T_WORD. This simplifies both the lexer and the parser. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:00 +09:00
kconfig: change "modules" from sub-option to first-level attribute Now "modules" is the only member of the "option" property. Remove "option", and move "modules" to the top level property. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-03-14 04:48:36 +09:00
kconfig: refactor scanning and parsing "option" properties For the keywords "modules", "defconfig_list", and "allnoconfig_y", the lexer should pass specific tokens instead of generic T_WORD. This simplifies both the lexer and the parser. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:00 +09:00
kconfig: add symbol option config syntax This adds the general framework to the parser to define options for config symbols with a syntax like: config FOO option bar[="arg"] Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-06-08 22:12:44 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: add named choice group As choice dependency are now fully checked, it's quite easy to add support for named choices. This lifts the restriction that a choice value can only appear once, although it still has to be within the same group, but multiple choices can be joined by giving them a name. While at it I cleaned up a little the choice type logic to simplify it a bit. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2008-02-29 05:11:50 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: add named choice group As choice dependency are now fully checked, it's quite easy to add support for named choices. This lifts the restriction that a choice value can only appear once, although it still has to be within the same group, but multiple choices can be joined by giving them a name. While at it I cleaned up a little the choice type logic to simplify it a bit. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2008-02-29 05:11:50 +01:00
kconfig: rename SYMBOL_AUTO to SYMBOL_NO_WRITE Over time, the use of the flag SYMBOL_AUTO changed from initially marking three automatically generated symbols ARCH, KERNELRELEASE and UNAME_RELEASE to today's effect of protecting symbols from being written out. Currently, only symbols of type CHOICE and those with option defconf_list set have that flag set. Reflect that change in semantics in the flag's name. Signed-off-by: Dirk Gouders <dirk@gouders.net> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-03 14:43:31 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: Don't leak choice names during parsing The named choice is not used in the kernel tree, but if it were used, it would not be freed. The intention of the named choice can be seen in the log of commit 5a1aa8a1aff6 ("kconfig: add named choice group"). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-02-20 20:40:29 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: refactor end token rules T_ENDMENU, T_ENDCHOICE, T_ENDIF are the last users of kconf_id associated with yylval. Refactor them to not use it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:06 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: allow only 'config', 'comment', and 'if' inside 'choice' The code block surrounded by 'if' ... 'endif' is reduced into if_stmt, which is accepted in the 'choice' context. Therefore, you can write any statements within a choice block by wrapping 'if y' ... 'end'. For example, you can create a menu inside a choice, like follows: ---------------->8---------------- choice prompt "choice" config A bool "A" config B bool "B" if y menu "strange menu" config C bool "C" endmenu endif endchoice ---------------->8---------------- I want to change such a weird structure into a syntax error. In fact, the USB gadget Kconfig had used nested 'choice' for no good reason until commit df8df5e4bc37 ("usb: get rid of 'choice' for legacy gadget drivers") killed it. I think the 'source' inside 'choice' is on the fence. It is at least gramatically sensible as long as the included file contains only bool/tristate configs. However, it makes the code unreadable, and people tend to forget the fact that the file is included from the choice block. Commit 10e5e6c24963 ("usb: gadget: move choice ... endchoice to legacy/Kconfig") got rid of the only usecase. Going forward, you can only use 'config', 'comment', and 'if' inside 'choice'. This also recursively applies to 'if' blocks inside 'choice'. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-24 14:49:29 +09:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: remove 'prompt' symbol Now that 'prompt' is only reduced from T_WORD_QUOTE without any action, use T_WORD_QUOTE directly. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2019-12-17 13:14:19 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: use distinct tokens for type and default properties This commit removes kconf_id::stype to prepare for the entire removal of kconf_id.c To simplify the lexer, I want keywords straight-mapped to tokens. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:59 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: use distinct tokens for type and default properties This commit removes kconf_id::stype to prepare for the entire removal of kconf_id.c To simplify the lexer, I want keywords straight-mapped to tokens. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:59 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: Don't leak symbol names during parsing Prior to this fix, zconf.y did not free symbol names from zconf.l in these contexts: - After T_CONFIG ('config LEAKED') - After T_MENUCONFIG ('menuconfig LEAKED') - After T_SELECT ('select LEAKED') - After T_IMPLY ('imply LEAKED') - After T_DEFAULT in a choice ('default LEAKED') All of these come in the form of T_WORD tokens, which always have their associated string allocated on the heap in zconf.l and need to be freed. Fix by introducing a new nonterminal 'nonconst_symbol' which takes a T_WORD, fetches the symbol, and then frees the T_WORD string. The already existing 'symbol' nonterminal works the same way but also accepts T_WORD_QUOTE, corresponding to a constant symbol. T_WORD_QUOTE should not be accepted in any of the contexts above, so the 'symbol' nonterminal can't be reused here. Fetching the symbol in 'nonconst_symbol' also removes a bunch of sym_lookup() calls from actions. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 711,571 bytes in 37,756 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 387,504 bytes in 15,545 blocks ... Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-08 19:11:18 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: use distinct tokens for type and default properties This commit removes kconf_id::stype to prepare for the entire removal of kconf_id.c To simplify the lexer, I want keywords straight-mapped to tokens. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:59 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: use distinct tokens for type and default properties This commit removes kconf_id::stype to prepare for the entire removal of kconf_id.c To simplify the lexer, I want keywords straight-mapped to tokens. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:59 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: fix line numbers for if-entries in menu tree The line numers for if-entries in the menu tree are off by one or more lines which is confusing when debugging for correctness of unrelated changes. According to the git log, commit a02f0570ae201c49 (kconfig: improve error handling in the parser) was the last one that changed that part of the parser and replaced "if_entry: T_IF expr T_EOL" by "if_entry: T_IF expr nl" but the commit message does not state why this has been done. When reverting that part of the commit, only the line numers are corrected (checked with cdebug = DEBUG_PARSE in zconf.y), otherwise the menu tree remains unchanged (checked with zconfdump() enabled in conf.c). An example for the corrected line numbers: drivers/soc/Kconfig:15:source drivers/soc/tegra/Kconfig drivers/soc/tegra/Kconfig:4:if drivers/soc/tegra/Kconfig:6:if changes to: drivers/soc/Kconfig:15:source drivers/soc/tegra/Kconfig drivers/soc/tegra/Kconfig:1:if drivers/soc/tegra/Kconfig:4:if Signed-off-by: Dirk Gouders <dirk@gouders.net> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-06-21 15:30:54 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: refactor end token rules T_ENDMENU, T_ENDCHOICE, T_ENDIF are the last users of kconf_id associated with yylval. Refactor them to not use it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:06 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: remove redundant if_block rule The code block surrounded by "if" ... "endif" is stmt_list. Remove the redundant if_block symbol entirely. Remove "stmt_list: stmt_list end" rule as well since it would obviously cause conflicts. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:54 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: allow only 'config', 'comment', and 'if' inside 'choice' The code block surrounded by 'if' ... 'endif' is reduced into if_stmt, which is accepted in the 'choice' context. Therefore, you can write any statements within a choice block by wrapping 'if y' ... 'end'. For example, you can create a menu inside a choice, like follows: ---------------->8---------------- choice prompt "choice" config A bool "A" config B bool "B" if y menu "strange menu" config C bool "C" endmenu endif endchoice ---------------->8---------------- I want to change such a weird structure into a syntax error. In fact, the USB gadget Kconfig had used nested 'choice' for no good reason until commit df8df5e4bc37 ("usb: get rid of 'choice' for legacy gadget drivers") killed it. I think the 'source' inside 'choice' is on the fence. It is at least gramatically sensible as long as the included file contains only bool/tristate configs. However, it makes the code unreadable, and people tend to forget the fact that the file is included from the choice block. Commit 10e5e6c24963 ("usb: gadget: move choice ... endchoice to legacy/Kconfig") got rid of the only usecase. Going forward, you can only use 'config', 'comment', and 'if' inside 'choice'. This also recursively applies to 'if' blocks inside 'choice'. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-24 14:49:29 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: remove 'prompt' symbol Now that 'prompt' is only reduced from T_WORD_QUOTE without any action, use T_WORD_QUOTE directly. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2019-12-17 13:14:19 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] kconfig: trivial cleanup Replace all menu_add_prop mimicking menu_add_prompt with the latter func. I've had to add a return value to menu_add_prompt for one usage. I've rebuilt scripts/kconfig/zconf.tab.c_shipped by hand to reflect changes in the source (I've not the same Bison version so regenerating it wouldn't have been not a good idea), and compared it with what Roman itself did some time ago, and it's the same. So I guess this can be finally merged. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-07-28 17:56:25 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: loosen the order of "visible" and "depends on" in menu entry Currently, "visible" and "depends on", if defined in a menu entry, must appear in that order. The real example is in drivers/media/tuners/Kconfig: menu "Customize TV tuners" visible if <expr1> depends on <expr2> ... is fine, but you cannot change the property order like this: menu "Customize TV tuners" depends on <expr2> visible if <expr1> Kconfig does not require a specific order of properties. In this case, menu_add_visibility(() and menu_add_dep() are orthogonal. Loosen this unreasonable restriction. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:56 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: refactor end token rules T_ENDMENU, T_ENDCHOICE, T_ENDIF are the last users of kconf_id associated with yylval. Refactor them to not use it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:06 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: remove redundant menu_block rule The code block surrounded by "menu" ... "endmenu" is stmt_list. Remove the redundant menu_block symbol entirely. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:55 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: loosen the order of "visible" and "depends on" in menu entry Currently, "visible" and "depends on", if defined in a menu entry, must appear in that order. The real example is in drivers/media/tuners/Kconfig: menu "Customize TV tuners" visible if <expr1> depends on <expr2> ... is fine, but you cannot change the property order like this: menu "Customize TV tuners" depends on <expr2> visible if <expr1> Kconfig does not require a specific order of properties. In this case, menu_add_visibility(() and menu_add_dep() are orthogonal. Loosen this unreasonable restriction. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:56 +09:00
kconfig: remove 'prompt' symbol Now that 'prompt' is only reduced from T_WORD_QUOTE without any action, use T_WORD_QUOTE directly. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2019-12-17 13:14:19 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
kconfig: Don't leak 'source' filenames during parsing The 'source_stmt' nonterminal takes a 'prompt', which consists of either a T_WORD or a T_WORD_QUOTE, both of which are always allocated on the heap in zconf.l and need to have their associated strings freed. Free them. The existing code already makes sure to always copy the string, but add a warning to sym_expand_string_value() to make it clear that the string must be copied, just in case. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 387,504 bytes in 15,545 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 344,616 bytes in 14,355 blocks ... Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-08 19:11:19 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: remove 'prompt' symbol Now that 'prompt' is only reduced from T_WORD_QUOTE without any action, use T_WORD_QUOTE directly. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2019-12-17 13:14:19 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] kconfig: trivial cleanup Replace all menu_add_prop mimicking menu_add_prompt with the latter func. I've had to add a return value to menu_add_prompt for one usage. I've rebuilt scripts/kconfig/zconf.tab.c_shipped by hand to reflect changes in the source (I've not the same Bison version so regenerating it wouldn't have been not a good idea), and compared it with what Roman itself did some time ago, and it's the same. So I guess this can be finally merged. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-07-28 17:56:25 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: rename depends_list to comment_option_list Now the comment_stmt is the only user of depends_list. Rename it to comment_option_list Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:57 +09:00
kconfig: Remove menu_end_entry() 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 <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-09 00:14:48 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: Warn if there is more than one help text Avoids mistakes like in the following real-world example, where only the final help string ("Say Y...") was used. This particular example was fixed in commit 561b29e4ec8d ("media: fix media Kconfig help syntax issues"). config DVB_NETUP_UNIDVB ... select DVB_CXD2841ER if MEDIA_SUBDRV_AUTOSELECT ---help--- Support for NetUP PCI express Universal DVB card. help Say Y when you want to support NetUP Dual Universal DVB card ... This now prints the following warning: drivers/media/pci/netup_unidvb:13: warning: 'DVB_NETUP_UNIDVB' defined with more than one help text -- only the last one will be used Also free() any extra help strings. Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-12 07:47:47 +01:00
kconfig: Warn if help text is blank Blank help texts are probably either a typo, a Kconfig misunderstanding, or some kind of half-committing to adding a help text (in which case a TODO comment would be clearer, if the help text really can't be added right away). Best to flag them, IMO. Example warning: drivers/mmc/host/Kconfig:877: warning: 'MMC_TOSHIBA_PCI' defined with blank help text Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-31 10:34:30 +01:00
kconfig: attach help text to menus Roman Zippel wrote: > A simple example would be > help texts, right now they are per symbol, but they should really be per > menu, so archs can provide different help texts for something. This patch does this and at the same time introduce a few API funtions used to access the help text. The relevant api functions are introduced in the various frontends. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Roman Zippel <zippel@linux-m68k.org>
2007-07-21 00:00:36 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: add an option to determine a menu's visibility This option is aimed to add the possibility to control a menu's visibility without adding dependency to the expression to all the submenu. Signed-off-by: Arnaud Lacombe <lacombar@gmail.com> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com> Tested-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-11-06 18:30:23 -03:00
kconfig: require T_EOL to reduce visible statement All line-oriented statements should be reduced when seeing a T_EOL token. I guess missing T_EOL for the "visible" statement is just a mistake. This commit decreases one shift/reduce conflict. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:00:46 +09:00
kconfig: add an option to determine a menu's visibility This option is aimed to add the possibility to control a menu's visibility without adding dependency to the expression to all the submenu. Signed-off-by: Arnaud Lacombe <lacombar@gmail.com> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com> Tested-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-11-06 18:30:23 -03:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: remove 'prompt' symbol Now that 'prompt' is only reduced from T_WORD_QUOTE without any action, use T_WORD_QUOTE directly. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2019-12-17 13:14:19 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] kconfig: trivial cleanup Replace all menu_add_prop mimicking menu_add_prompt with the latter func. I've had to add a return value to menu_add_prompt for one usage. I've rebuilt scripts/kconfig/zconf.tab.c_shipped by hand to reflect changes in the source (I've not the same Bison version so regenerating it wouldn't have been not a good idea), and compared it with what Roman itself did some time ago, and it's the same. So I guess this can be finally merged. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-07-28 17:56:25 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: refactor end token rules T_ENDMENU, T_ENDCHOICE, T_ENDIF are the last users of kconf_id associated with yylval. Refactor them to not use it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:06 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: allow use of relations other than (in)equality Over the years I found it desirable to be able to use all sorts of relations, not just (in)equality. And apparently I'm not the only one, as there's at least one example in the tree where the programmer assumed this would work (see DEBUG_UART_8250_WORD in arch/arm/Kconfig.debug). Another possible use would e.g. be to fold the two SMP/NR_CPUS prompts into one: SMP could be promptless, simply depending on NR_CPUS > 1. A (desirable) side effect of this change - resulting from numeric values now necessarily being compared as numbers rather than as strings - is that comparing hex values now works as expected: Other than int ones (which aren't allowed to have leading zeroes), zeroes following the 0x prefix made them compare unequal even if their values were equal. Signed-off-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2015-06-15 13:00:21 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: Don't leak symbol names during parsing Prior to this fix, zconf.y did not free symbol names from zconf.l in these contexts: - After T_CONFIG ('config LEAKED') - After T_MENUCONFIG ('menuconfig LEAKED') - After T_SELECT ('select LEAKED') - After T_IMPLY ('imply LEAKED') - After T_DEFAULT in a choice ('default LEAKED') All of these come in the form of T_WORD tokens, which always have their associated string allocated on the heap in zconf.l and need to be freed. Fix by introducing a new nonterminal 'nonconst_symbol' which takes a T_WORD, fetches the symbol, and then frees the T_WORD string. The already existing 'symbol' nonterminal works the same way but also accepts T_WORD_QUOTE, corresponding to a constant symbol. T_WORD_QUOTE should not be accepted in any of the contexts above, so the 'symbol' nonterminal can't be reused here. Fetching the symbol in 'nonconst_symbol' also removes a bunch of sym_lookup() calls from actions. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 711,571 bytes in 37,756 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 387,504 bytes in 15,545 blocks ... Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-08 19:11:18 +02:00
kconfig: add named choice group As choice dependency are now fully checked, it's quite easy to add support for named choices. This lifts the restriction that a choice value can only appear once, although it still has to be within the same group, but multiple choices can be joined by giving them a name. While at it I cleaned up a little the choice type logic to simplify it a bit. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2008-02-29 05:11:50 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: add named choice group As choice dependency are now fully checked, it's quite easy to add support for named choices. This lifts the restriction that a choice value can only appear once, although it still has to be within the same group, but multiple choices can be joined by giving them a name. While at it I cleaned up a little the choice type logic to simplify it a bit. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2008-02-29 05:11:50 +01:00
kconfig: support user-defined function and recursively expanded variable Now, we got a basic ability to test compiler capability in Kconfig. config CC_HAS_STACKPROTECTOR def_bool $(shell,($(CC) -Werror -fstack-protector -E -x c /dev/null -o /dev/null 2>/dev/null) && echo y || echo n) This works, but it is ugly to repeat this long boilerplate. We want to describe like this: config CC_HAS_STACKPROTECTOR bool default $(cc-option,-fstack-protector) It is straight-forward to add a new function, but I do not like to hard-code specialized functions like that. Hence, here is another feature, user-defined function. This works as a textual shorthand with parameterization. A user-defined function is defined by using the = operator, and can be referenced in the same way as built-in functions. A user-defined function in Make is referenced like $(call my-func,arg1,arg2), but I omitted the 'call' to make the syntax shorter. The definition of a user-defined function contains $(1), $(2), etc. in its body to reference the parameters. It is grammatically valid to pass more or fewer arguments when calling it. We already exploit this feature in our makefiles; scripts/Kbuild.include defines cc-option which takes two arguments at most, but most of the callers pass only one argument. By the way, a variable is supported as a subset of this feature since a variable is "a user-defined function with zero argument". In this context, I mean "variable" as recursively expanded variable. I will add a different flavored variable in the next commit. The code above can be written as follows: [Example Code] success = $(shell,($(1)) >/dev/null 2>&1 && echo y || echo n) cc-option = $(success,$(CC) -Werror $(1) -E -x c /dev/null -o /dev/null) config CC_HAS_STACKPROTECTOR def_bool $(cc-option,-fstack-protector) [Result] $ make -s alldefconfig && tail -n 1 .config CONFIG_CC_HAS_STACKPROTECTOR=y Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-05-28 18:21:49 +09:00
kconfig: use T_WORD instead of T_VARIABLE for variables There is no grammatical ambiguity by using T_WORD for variables. The parser can distinguish variables from symbols from the context. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:02 +09:00
kconfig: use specific tokens instead of T_ASSIGN for assignments Currently, the lexer returns T_ASSIGN for all of =, :=, and += associating yylval with the flavor. I want to make the generated lexer as simple as possible. So, the lexer should convert keywords to tokens without thinking about the meaning. = -> T_EQUAL := -> T_COLON_EQUAL += -> T_PLUS_EQUAL Unfortunately, Kconfig uses = instead of == for the equal operator. So, the same token T_EQUAL is used for assignment and comparison. The parser can still distinguish them from the context. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:01 +09:00
kconfig: support user-defined function and recursively expanded variable Now, we got a basic ability to test compiler capability in Kconfig. config CC_HAS_STACKPROTECTOR def_bool $(shell,($(CC) -Werror -fstack-protector -E -x c /dev/null -o /dev/null 2>/dev/null) && echo y || echo n) This works, but it is ugly to repeat this long boilerplate. We want to describe like this: config CC_HAS_STACKPROTECTOR bool default $(cc-option,-fstack-protector) It is straight-forward to add a new function, but I do not like to hard-code specialized functions like that. Hence, here is another feature, user-defined function. This works as a textual shorthand with parameterization. A user-defined function is defined by using the = operator, and can be referenced in the same way as built-in functions. A user-defined function in Make is referenced like $(call my-func,arg1,arg2), but I omitted the 'call' to make the syntax shorter. The definition of a user-defined function contains $(1), $(2), etc. in its body to reference the parameters. It is grammatically valid to pass more or fewer arguments when calling it. We already exploit this feature in our makefiles; scripts/Kbuild.include defines cc-option which takes two arguments at most, but most of the callers pass only one argument. By the way, a variable is supported as a subset of this feature since a variable is "a user-defined function with zero argument". In this context, I mean "variable" as recursively expanded variable. I will add a different flavored variable in the next commit. The code above can be written as follows: [Example Code] success = $(shell,($(1)) >/dev/null 2>&1 && echo y || echo n) cc-option = $(success,$(CC) -Werror $(1) -E -x c /dev/null -o /dev/null) config CC_HAS_STACKPROTECTOR def_bool $(cc-option,-fstack-protector) [Result] $ make -s alldefconfig && tail -n 1 .config CONFIG_CC_HAS_STACKPROTECTOR=y Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-05-28 18:21:49 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: new configuration interface (nconfig) This patch was inspired by the kernel projects page, where an ncurses replacement for menuconfig was mentioned (by Sam Ravnborg). Building on menuconfig, this patch implements a more modern look interface using ncurses and ncurses' satellite libraries (menu, panel, form). The implementation does not depend on lxdialog, which is currently distributed with the kernel. Signed-off-by: Nir Tzachar <nir.tzachar@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2009-11-25 12:28:43 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
kconfig: use default 'yy' prefix for lexer and parser Flex and Bison provide an option to change the prefix of globally- visible symbols. This is useful to link multiple lexers and/or parsers into the same executable. However, Kconfig (and any other host programs in kernel) uses a single lexer and parser. I do not see a good reason to change the default 'yy' prefix. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-01-12 00:50:50 +09:00
kconfig: support user-defined function and recursively expanded variable Now, we got a basic ability to test compiler capability in Kconfig. config CC_HAS_STACKPROTECTOR def_bool $(shell,($(CC) -Werror -fstack-protector -E -x c /dev/null -o /dev/null 2>/dev/null) && echo y || echo n) This works, but it is ugly to repeat this long boilerplate. We want to describe like this: config CC_HAS_STACKPROTECTOR bool default $(cc-option,-fstack-protector) It is straight-forward to add a new function, but I do not like to hard-code specialized functions like that. Hence, here is another feature, user-defined function. This works as a textual shorthand with parameterization. A user-defined function is defined by using the = operator, and can be referenced in the same way as built-in functions. A user-defined function in Make is referenced like $(call my-func,arg1,arg2), but I omitted the 'call' to make the syntax shorter. The definition of a user-defined function contains $(1), $(2), etc. in its body to reference the parameters. It is grammatically valid to pass more or fewer arguments when calling it. We already exploit this feature in our makefiles; scripts/Kbuild.include defines cc-option which takes two arguments at most, but most of the callers pass only one argument. By the way, a variable is supported as a subset of this feature since a variable is "a user-defined function with zero argument". In this context, I mean "variable" as recursively expanded variable. I will add a different flavored variable in the next commit. The code above can be written as follows: [Example Code] success = $(shell,($(1)) >/dev/null 2>&1 && echo y || echo n) cc-option = $(success,$(CC) -Werror $(1) -E -x c /dev/null -o /dev/null) config CC_HAS_STACKPROTECTOR def_bool $(cc-option,-fstack-protector) [Result] $ make -s alldefconfig && tail -n 1 .config CONFIG_CC_HAS_STACKPROTECTOR=y Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-05-28 18:21:49 +09:00
kconfig: use default 'yy' prefix for lexer and parser Flex and Bison provide an option to change the prefix of globally- visible symbols. This is useful to link multiple lexers and/or parsers into the same executable. However, Kconfig (and any other host programs in kernel) uses a single lexer and parser. I do not see a good reason to change the default 'yy' prefix. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-01-12 00:50:50 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: do not special-case 'MODULES' symbol Currently, the 'MODULES' symbol is hard-coded to be the default symbol that enables/disables tristates, if no other symbol was declared with 'option modules'. While this used to be needed for the Linux kernel, we now have an explicit 'option modules' attached to the 'MODULES' symbol (since cset 11097a036), so we no longer need to special-case it in the kconfig code. Furthermore, kconfig is extensively used out of the Linux kernel, and other projects may have another meaning for a symbol named 'MODULES'. This patch changes the way we enable/disable tristates: if a symbol was found with 'option modules' attached to it, then that symbol controls enabling tristates. Otherwise, tristates are disabled, even if a symbol named 'MODULES' exists. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Michal Marek <mmarek@suse.cz>
2013-09-03 17:07:18 +02:00
kconfig: expand by default the rootmenu's prompt Signed-off-by: Arnaud Lacombe <lacombar@gmail.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Michal Marek <mmarek@suse.cz>
2010-09-09 21:17:26 -04:00
kconfig: remove string expansion for mainmenu after yyparse() Now that environments are expanded in the lexer, conf_parse() does not need to expand them explicitly. The hack introduced by commit 0724a7c32a54 ("kconfig: Don't leak main menus during parsing") can go away. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-05-28 18:21:42 +09:00
kconfig: make default prompt of mainmenu less specific If "mainmenu" is not specified, "Linux Kernel Configuration" is used as a default prompt. Given that Kconfig is used in other projects than Linux, let's use a more generic prompt, "Main menu". Suggested-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-05-28 18:21:44 +09:00
kconfig: remove string expansion for mainmenu after yyparse() Now that environments are expanded in the lexer, conf_parse() does not need to expand them explicitly. The hack introduced by commit 0724a7c32a54 ("kconfig: Don't leak main menus during parsing") can go away. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-05-28 18:21:42 +09:00
kconfig: expand by default the rootmenu's prompt Signed-off-by: Arnaud Lacombe <lacombar@gmail.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Michal Marek <mmarek@suse.cz>
2010-09-09 21:17:26 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: error out if recursive dependencies are found Sample: config FOO bool "This is foo" depends on BAR config BAR bool "This is bar" depends on FOO This will result in following error message: error: found recursive dependency: FOO -> BAR -> FOO And will then exit with exit code equal 1 so make will stop. Inspired by patch from: Adrian Bunk <bunk@stusta.de> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Adrian Bunk <bunk@stusta.de> Cc: Roman Zippel <zippel@linux-m68k.org>
2007-05-06 09:20:10 +02:00
kconfig: use default 'yy' prefix for lexer and parser Flex and Bison provide an option to change the prefix of globally- visible symbols. This is useful to link multiple lexers and/or parsers into the same executable. However, Kconfig (and any other host programs in kernel) uses a single lexer and parser. I do not see a good reason to change the default 'yy' prefix. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-01-12 00:50:50 +09:00
kbuild: trivial - use tabs for code indent where possible Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2014-06-10 19:08:13 +09:00
kconfig: use default 'yy' prefix for lexer and parser Flex and Bison provide an option to change the prefix of globally- visible symbols. This is useful to link multiple lexers and/or parsers into the same executable. However, Kconfig (and any other host programs in kernel) uses a single lexer and parser. I do not see a good reason to change the default 'yy' prefix. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-01-12 00:50:50 +09:00
kconfig: error out if recursive dependencies are found Sample: config FOO bool "This is foo" depends on BAR config BAR bool "This is bar" depends on FOO This will result in following error message: error: found recursive dependency: FOO -> BAR -> FOO And will then exit with exit code equal 1 so make will stop. Inspired by patch from: Adrian Bunk <bunk@stusta.de> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Adrian Bunk <bunk@stusta.de> Cc: Roman Zippel <zippel@linux-m68k.org>
2007-05-06 09:20:10 +02:00
kconfig: change sym_change_count to a boolean flag sym_change_count has no good reason to be 'int' type. sym_set_change_count() compares the old and new values after casting both of them to (bool). I do not see any practical diffrence between sym_set_change_count(1) and sym_add_change_count(1). Use the boolean flag, conf_changed. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-04-10 15:57:22 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: refactor end token rules T_ENDMENU, T_ENDCHOICE, T_ENDIF are the last users of kconf_id associated with yylval. Refactor them to not use it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:06 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: refactor end token rules T_ENDMENU, T_ENDCHOICE, T_ENDIF are the last users of kconf_id associated with yylval. Refactor them to not use it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:06 +09:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
kconfig: refactor end token rules T_ENDMENU, T_ENDCHOICE, T_ENDIF are the last users of kconf_id associated with yylval. Refactor them to not use it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:06 +09:00
kconfig: use default 'yy' prefix for lexer and parser Flex and Bison provide an option to change the prefix of globally- visible symbols. This is useful to link multiple lexers and/or parsers into the same executable. However, Kconfig (and any other host programs in kernel) uses a single lexer and parser. I do not see a good reason to change the default 'yy' prefix. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-01-12 00:50:50 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
kconfig: refactor end token rules T_ENDMENU, T_ENDCHOICE, T_ENDIF are the last users of kconf_id associated with yylval. Refactor them to not use it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:06 +09:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
kconfig: refactor end token rules T_ENDMENU, T_ENDCHOICE, T_ENDIF are the last users of kconf_id associated with yylval. Refactor them to not use it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-11 20:01:06 +09:00
kconfig: use default 'yy' prefix for lexer and parser Flex and Bison provide an option to change the prefix of globally- visible symbols. This is useful to link multiple lexers and/or parsers into the same executable. However, Kconfig (and any other host programs in kernel) uses a single lexer and parser. I do not see a good reason to change the default 'yy' prefix. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-01-12 00:50:50 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
kconfig: use default 'yy' prefix for lexer and parser Flex and Bison provide an option to change the prefix of globally- visible symbols. This is useful to link multiple lexers and/or parsers into the same executable. However, Kconfig (and any other host programs in kernel) uses a single lexer and parser. I do not see a good reason to change the default 'yy' prefix. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-01-12 00:50:50 +09:00
[PATCH] kconfig: improve error handling in the parser Add a few error tokens to the parser to catch common errors and print more descriptive error messages. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:34:53 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: use default 'yy' prefix for lexer and parser Flex and Bison provide an option to change the prefix of globally- visible symbols. This is useful to link multiple lexers and/or parsers into the same executable. However, Kconfig (and any other host programs in kernel) uses a single lexer and parser. I do not see a good reason to change the default 'yy' prefix. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-01-12 00:50:50 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: Mark various internal functions static kconfig's keyword hash, lexer, and parser define various functions used only locally. Declare these functions as static, and regenerate the corresponding generated files. Signed-off-by: Josh Triplett <josh@joshtriplett.org>
2009-10-15 12:13:36 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: Mark various internal functions static kconfig's keyword hash, lexer, and parser define various functions used only locally. Declare these functions as static, and regenerate the corresponding generated files. Signed-off-by: Josh Triplett <josh@joshtriplett.org>
2009-10-15 12:13:36 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: fix zconfdump() zconfdump(), which is used for debugging, can't recognize P_SELECT, P_RANGE and P_MENU (if associated with a symbol, aka "menuconfig"), and output something like this: config X86 boolean default y unknown prop 6! unknown prop 6! unknown prop 6! ... Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-04-14 11:44:20 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: fix zconfdump() zconfdump(), which is used for debugging, can't recognize P_SELECT, P_RANGE and P_MENU (if associated with a symbol, aka "menuconfig"), and output something like this: config X86 boolean default y unknown prop 6! unknown prop 6! unknown prop 6! ... Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-04-14 11:44:20 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: drop 'boolean' keyword No more users of this keyword. Drop it according to the notice by commit 6341e62b212a ("kconfig: use bool instead of boolean for type definition attributes"). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
2017-12-16 00:38:02 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: fix zconfdump() zconfdump(), which is used for debugging, can't recognize P_SELECT, P_RANGE and P_MENU (if associated with a symbol, aka "menuconfig"), and output something like this: config X86 boolean default y unknown prop 6! unknown prop 6! unknown prop 6! ... Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-04-14 11:44:20 +08:00
Kconfig: Introduce the "imply" keyword The "imply" keyword is a weak version of "select" where the target config symbol can still be turned off, avoiding those pitfalls that come with the "select" keyword. This is useful e.g. with multiple drivers that want to indicate their ability to hook into a secondary subsystem while allowing the user to configure that subsystem out without also having to unset these drivers. Currently, the same effect can almost be achieved with: config DRIVER_A tristate config DRIVER_B tristate config DRIVER_C tristate config DRIVER_D tristate [...] config SUBSYSTEM_X tristate default DRIVER_A || DRIVER_B || DRIVER_C || DRIVER_D || [...] This is unwieldy to maintain especially with a large number of drivers. Furthermore, there is no easy way to restrict the choice for SUBSYSTEM_X to y or n, excluding m, when some drivers are built-in. The "select" keyword allows for excluding m, but it excludes n as well. Hence this "imply" keyword. The above becomes: config DRIVER_A tristate imply SUBSYSTEM_X config DRIVER_B tristate imply SUBSYSTEM_X [...] config SUBSYSTEM_X tristate This is much cleaner, and way more flexible than "select". SUBSYSTEM_X can still be configured out, and it can be set as a module when none of the drivers are configured in or all of them are modular. Signed-off-by: Nicolas Pitre <nico@linaro.org> Acked-by: Richard Cochran <richardcochran@gmail.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Cc: Paul Bolle <pebolle@tiscali.nl> Cc: linux-kbuild@vger.kernel.org Cc: netdev@vger.kernel.org Cc: Michal Marek <mmarek@suse.com> Cc: Edward Cree <ecree@solarflare.com> Link: http://lkml.kernel.org/r/1478841010-28605-2-git-send-email-nicolas.pitre@linaro.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2016-11-11 00:10:05 -05:00
kconfig: fix zconfdump() zconfdump(), which is used for debugging, can't recognize P_SELECT, P_RANGE and P_MENU (if associated with a symbol, aka "menuconfig"), and output something like this: config X86 boolean default y unknown prop 6! unknown prop 6! unknown prop 6! ... Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-04-14 11:44:20 +08:00
kconfig: handle P_SYMBOL in print_symbol() Each symbol has a property of type P_SYMBOL since commit 59e89e3ddf85 (kconfig: save location of config symbols). Handle those properties in print_symbol(). Further, place a pointer to print_symbol() in the comment above the list of known property type. Signed-off-by: Dirk Gouders <dirk@gouders.net> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-06-22 21:27:38 +02:00
kconfig: remove sym from struct property struct property can reference to the symbol that it is associated with by prop->menu->sym. Fix up the one usage of prop->sym, and remove sym from struct property. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2019-12-17 13:14:22 +09:00
kconfig: handle P_SYMBOL in print_symbol() Each symbol has a property of type P_SYMBOL since commit 59e89e3ddf85 (kconfig: save location of config symbols). Handle those properties in print_symbol(). Further, place a pointer to print_symbol() in the comment above the list of known property type. Signed-off-by: Dirk Gouders <dirk@gouders.net> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-06-22 21:27:38 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kconfig: attach help text to menus Roman Zippel wrote: > A simple example would be > help texts, right now they are per symbol, but they should really be per > menu, so archs can provide different help texts for something. This patch does this and at the same time introduce a few API funtions used to access the help text. The relevant api functions are introduced in the various frontends. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Roman Zippel <zippel@linux-m68k.org>
2007-07-21 00:00:36 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00