kernel/linux.git/scripts/kconfig/symbol.c, branch v5.2.1

kconfig: split some C files out of zconf.y

2018-12-28T13:22:38+00:00

I want to compile each C file independently instead of including all of them from zconf.y. Split out confdata.c, expr.c, symbol.c, and preprocess.c . These are low-hanging fruits. Signed-off-by: Masahiro Yamada

kconfig: convert to SPDX License Identifier

2018-12-28T13:22:28+00:00

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

kconfig: remove S_OTHER symbol type and correct dependency tracking

2018-12-08T01:42:41+00:00

The S_OTHER type could be set only when conf_read_simple() is reading include/config/auto.conf file. For example, CONFIG_FOO=y exists in include/config/auto.conf but it is missing from the currently parsed Kconfig files, sym_lookup() allocates a new symbol, and sets its type to S_OTHER. Strangely, it will be set to S_STRING by conf_set_sym_val() a few lines below while it is obviously bool or tristate type. On the other hand, when CONFIG_BAR="bar" is being dropped from include/config/auto.conf, its type remains S_OTHER. Because for_all_symbols() omits S_OTHER symbols, conf_touch_deps() misses to touch include/config/bar.h This behavior has been a pretty mystery for me, and digging the git histroy did not help. At least, touching depfiles is broken for string type symbols. I removed S_OTHER entirely, and reimplemented it more simply. If CONFIG_FOO was visible in the previous syncconfig, but is missing now, what we want to do is quite simple; just call conf_touch_dep() to touch include/config/foo.h instead of allocating a new symbol data. Signed-off-by: Masahiro Yamada

kconfig: improve the recursive dependency report

2018-08-22T14:21:39+00:00

This commit improves the messages of the recursive dependency. Currently, sym->dir_dep.expr is not checked. Hence, any dependency in property visibility is regarded as the dependency of the symbol. [Test Code 1] config A bool "a" depends on B config B bool "b" depends on A [Test Code 2] config A bool "a" if B config B bool "b" depends on A For both cases above, the same message is displayed: symbol B depends on A symbol A depends on B This commit changes the message for the latter, like this: symbol B depends on A symbol A prompt is visible depending on B Also, 'select' and 'imply' are distinguished. Signed-off-by: Masahiro Yamada Tested-by: Dirk Gouders

kconfig: report recursive dependency involving 'imply'

2018-08-22T14:21:39+00:00

Currently, Kconfig does not complain about the recursive dependency where 'imply' keywords are involved. [Test Code] config A bool "a" config B bool "b" imply A depends on A In the code above, Kconfig cannot calculate the symbol values correctly due to the circular dependency. For example, allyesconfig followed by syncconfig results in an odd behavior because CONFIG_B becomes visible in syncconfig. $ make allyesconfig scripts/kconfig/conf --allyesconfig Kconfig # # configuration written to .config # $ cat .config # # Automatically generated file; DO NOT EDIT. # Main menu # CONFIG_A=y $ make syncconfig scripts/kconfig/conf --syncconfig Kconfig * * Restart config... * * * Main menu * a (A) [Y/n/?] y b (B) [N/y/?] (NEW) To detect this correctly, sym_check_expr_deps() should recurse to not only sym->rev_dep.expr but also sym->implied.expr . At this moment, sym_check_print_recursive() cannot distinguish 'select' and 'imply' since it does not know the precise context where the recursive dependency has been hit. This will be solved by the next commit. In fact, even the document and the unit-test are confused. Using 'imply' does not solve recursive dependency since 'imply' addresses the unmet direct dependency, which 'select' could cause. Signed-off-by: Masahiro Yamada Tested-by: Dirk Gouders

kconfig: error out when seeing recursive dependency

2018-08-22T14:21:38+00:00

Originally, recursive dependency was a fatal error for Kconfig because Kconfig cannot compute symbol values in such a situation. Commit d595cea62403 ("kconfig: print more info when we see a recursive dependency") changed it to a warning, which I guess was not intentional. Get it back to an error again. Also, rename the unit test directory "warn_recursive_dep" to "err_recursive_dep" so that it matches to the behavior. Signed-off-by: Masahiro Yamada Tested-by: Dirk Gouders

kconfig: remove P_ENV property type

2018-08-14T00:01:47+00:00

This property is not set by anyone since commit 104daea149c4 ("kconfig: reference environment variables directly and remove 'option env='"). Signed-off-by: Masahiro Yamada Acked-by: Sam Ravnborg

kconfig: remove unused sym_get_env_prop() function

2018-08-13T23:59:57+00:00

This function is unused since commit 104daea149c4 ("kconfig: reference environment variables directly and remove 'option env='"). Signed-off-by: Masahiro Yamada Acked-by: Sam Ravnborg

kconfig: rename SYMBOL_AUTO to SYMBOL_NO_WRITE

2018-07-17T16:18:09+00:00

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 Signed-off-by: Masahiro Yamada

kconfig: remove sym_expand_string_value()

2018-05-28T18:31:19+00:00

There is no more caller of sym_expand_string_value(). Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook