summaryrefslogtreecommitdiff
path: root/scripts/kconfig
AgeCommit message (Collapse)AuthorFilesLines
2025-12-01kconfig/nconf: Initialize the default locale at startupJakub Horký1-0/+3
[ Upstream commit 43c2931a95e6b295bfe9e3b90dbe0f7596933e91 ] Fix bug where make nconfig doesn't initialize the default locale, which causes ncurses menu borders to be displayed incorrectly (lqqqqk) in UTF-8 terminals that don't support VT100 ACS by default, such as PuTTY. Signed-off-by: Jakub Horký <jakub.git@horky.net> Link: https://patch.msgid.link/20251014144405.3975275-2-jakub.git@horky.net [nathan: Alphabetize locale.h include] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-12-01kconfig/mconf: Initialize the default locale at startupJakub Horký1-0/+3
[ Upstream commit 3927c4a1084c48ef97f11281a0a43ecb2cb4d6f1 ] Fix bug where make menuconfig doesn't initialize the default locale, which causes ncurses menu borders to be displayed incorrectly (lqqqqk) in UTF-8 terminals that don't support VT100 ACS by default, such as PuTTY. Signed-off-by: Jakub Horký <jakub.git@horky.net> Link: https://patch.msgid.link/20251014154933.3990990-1-jakub.git@horky.net [nathan: Alphabetize locale.h include] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-20kconfig: lxdialog: fix 'space' to (de)select optionsYann E. MORIN1-1/+1
[ Upstream commit 694174f94ebeeb5ec5cc0e9de9b40c82057e1d95 ] In case a menu has comment without letters/numbers (eg. characters matching the regexp '^[^[:alpha:][:digit:]]+$', for example - or *), hitting space will cycle through those comments, rather than selecting/deselecting the currently-highlighted option. This is the behaviour of hitting any letter/digit: jump to the next option which prompt starts with that letter. The only letters that do not behave as such are 'y' 'm' and 'n'. Prompts that start with one of those three letters are instead matched on the first letter that is not 'y', 'm' or 'n'. Fix that by treating 'space' as we treat y/m/n, ie. as an action key, not as shortcut to jump to prompt. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Cherniaev Andrei <dungeonlords789@naver.com> [masahiro: took from Buildroot, adjusted the commit subject] Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-20kconfig: gconf: fix potential memory leak in renderer_edited()Masahiro Yamada1-1/+2
[ Upstream commit f72ed4c6a375e52a3f4b75615e4a89d29d8acea7 ] If gtk_tree_model_get_iter() fails, gtk_tree_path_free() is not called. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-20kconfig: gconf: avoid hardcoding model2 in on_treeview2_cursor_changed()Masahiro Yamada1-2/+3
[ Upstream commit cae9cdbcd9af044810bcceeb43a87accca47c71d ] The on_treeview2_cursor_changed() handler is connected to both the left and right tree views, but it hardcodes model2 (the GtkTreeModel of the right tree view). This is incorrect. Get the associated model from the view. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-20kconfig: nconf: Ensure null termination where strncpy is usedShankari Anand2-0/+3
[ Upstream commit f468992936894c9ce3b1659cf38c230d33b77a16 ] strncpy() does not guarantee null-termination if the source string is longer than the destination buffer. Ensure the buffer is explicitly null-terminated to prevent potential string overflows or undefined behavior. Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Nicolas Schier <n.schier@avm.de> Acked-by: Nicolas Schier <n.schier@avm.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-20kconfig: lxdialog: replace strcpy() with strncpy() in inputbox.cSuchit Karunakaran1-2/+4
[ Upstream commit 5ac726653a1029a2eccba93bbe59e01fc9725828 ] strcpy() performs no bounds checking and can lead to buffer overflows if the input string exceeds the destination buffer size. This patch replaces it with strncpy(), and null terminates the input string. Signed-off-by: Suchit Karunakaran <suchitkarunakaran@gmail.com> Reviewed-by: Nicolas Schier <nicolas.schier@linux.dev> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15kconfig: qconf: fix ConfigList::updateListAllforAll()Masahiro Yamada1-1/+1
[ Upstream commit 721bfe583c52ba1ea74b3736a31a9dcfe6dd6d95 ] ConfigList::updateListForAll() and ConfigList::updateListAllforAll() are identical. Commit f9b918fae678 ("kconfig: qconf: move ConfigView::updateList(All) to ConfigList class") was a misconversion. Fixes: f9b918fae678 ("kconfig: qconf: move ConfigView::updateList(All) to ConfigList class") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-29kconfig: do not clear SYMBOL_VALID when reading include/config/auto.confMasahiro Yamada1-7/+12
[ Upstream commit 226ac19c217f24f0927d0a73cf9ee613971a188d ] When conf_read_simple() is called with S_DEF_AUTO, it is meant to read previous symbol values from include/config/auto.conf to determine which include/config/* files should be touched. This process should not modify the current symbol status in any way. However, conf_touch_deps() currently invalidates all symbol values and recalculates them, which is totally unneeded. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-29kconfig: merge_config: use an empty file as initfileDaniel Gomez1-2/+2
[ Upstream commit a26fe287eed112b4e21e854f173c8918a6a8596d ] The scripts/kconfig/merge_config.sh script requires an existing $INITFILE (or the $1 argument) as a base file for merging Kconfig fragments. However, an empty $INITFILE can serve as an initial starting point, later referenced by the KCONFIG_ALLCONFIG Makefile variable if -m is not used. This variable can point to any configuration file containing preset config symbols (the merged output) as stated in Documentation/kbuild/kconfig.rst. When -m is used $INITFILE will contain just the merge output requiring the user to run make (i.e. KCONFIG_ALLCONFIG=<$INITFILE> make <allnoconfig/alldefconfig> or make olddefconfig). Instead of failing when `$INITFILE` is missing, create an empty file and use it as the starting point for merges. Signed-off-by: Daniel Gomez <da.gomez@samsung.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-21kbuild: suppress stdout from merge_config for silent buildsMasahiro Yamada1-1/+3
[ Upstream commit 1f937a4bcb0472015818f30f4d3c5546d3f09933 ] merge_config does not respect the Make's -s (--silent) option. Let's sink the stdout from merge_config for silent builds. This commit does not cater to the direct invocation of merge_config.sh (e.g. arch/mips/Makefile). Reported-by: Leon Romanovsky <leon@kernel.org> Closes: https://lore.kernel.org/all/e534ce33b0e1060eb85ece8429810f087b034c88.1733234008.git.leonro@nvidia.com/ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Leon Romanovsky <leon@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08kconfig: fix memory leak in sym_warn_unmet_dep()Masahiro Yamada1-0/+1
[ Upstream commit a409fc1463d664002ea9bf700ae4674df03de111 ] The string allocated in sym_warn_unmet_dep() is never freed, leading to a memory leak when an unmet dependency is detected. Fixes: f8f69dc0b4e0 ("kconfig: make unmet dependency warnings readable") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Petr Vorel <pvorel@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08kconfig: fix file name in warnings when loading KCONFIG_DEFCONFIG_LISTMasahiro Yamada1-2/+4
[ Upstream commit a314f52a0210730d0d556de76bb7388e76d4597d ] Most 'make *config' commands use .config as the base configuration file. When .config does not exist, Kconfig tries to load a file listed in KCONFIG_DEFCONFIG_LIST instead. However, since commit b75b0a819af9 ("kconfig: change defconfig_list option to environment variable"), warning messages have displayed an incorrect file name in such cases. Below is a demonstration using Debian Trixie. While loading /boot/config-6.12.9-amd64, the warning messages incorrectly show .config as the file name. With this commit, the correct file name is displayed in warnings. [Before] $ rm -f .config $ make config # # using defaults found in /boot/config-6.12.9-amd64 # .config:6804:warning: symbol value 'm' invalid for FB_BACKLIGHT .config:9895:warning: symbol value 'm' invalid for ANDROID_BINDER_IPC [After] $ rm -f .config $ make config # # using defaults found in /boot/config-6.12.9-amd64 # /boot/config-6.12.9-amd64:6804:warning: symbol value 'm' invalid for FB_BACKLIGHT /boot/config-6.12.9-amd64:9895:warning: symbol value 'm' invalid for ANDROID_BINDER_IPC Fixes: b75b0a819af9 ("kconfig: change defconfig_list option to environment variable") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-31kconfig: show sub-menu entries even if the prompt is hiddenMasahiro Yamada1-1/+12
Since commit f79dc03fe68c ("kconfig: refactor choice value calculation"), when EXPERT is disabled, nothing within the "if INPUT" ... "endif" block in drivers/input/Kconfig is displayed. This issue affects all command-line interfaces and GUI frontends. The prompt for INPUT is hidden when EXPERT is disabled. Previously, menu_is_visible() returned true in this case; however, it now returns false, resulting in all sub-menu entries being skipped. Here is a simplified test case illustrating the issue: config A bool "A" if X default y config B bool "B" depends on A When X is disabled, A becomes unconfigurable and is forced to y. B should be displayed, as its dependency is met. This commit restores the necessary code, so menu_is_visible() functions as it did previously. Fixes: f79dc03fe68c ("kconfig: refactor choice value calculation") Reported-by: Edmund Raile <edmund.raile@proton.me> Closes: https://lore.kernel.org/all/5fd0dfc7ff171aa74352e638c276069a5f2e888d.camel@proton.me/ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-10-02kconfig: qconf: fix buffer overflow in debug linksMasahiro Yamada1-1/+1
If you enable "Option -> Show Debug Info" and click a link, the program terminates with the following error: *** buffer overflow detected ***: terminated The buffer overflow is caused by the following line: strcat(data, "$"); The buffer needs one more byte to accommodate the additional character. Fixes: c4f7398bee9c ("kconfig: qconf: make debug links work again") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-10-01kconfig: qconf: move conf_read() before drawing tree painMasahiro Yamada1-2/+2
The constructor of ConfigMainWindow() calls show*View(), which needs to calculate symbol values. conf_read() must be called before that. Fixes: 060e05c3b422 ("kconfig: qconf: remove initial call to conf_changed()") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-10-01kconfig: clear expr::val_is_valid when allocatedMasahiro Yamada1-0/+1
Since commit 95573cac25c6 ("kconfig: cache expression values"), xconfig emits a lot of false-positive "unmet direct dependencies" warnings. While conf_read() clears val_is_valid flags, 'make xconfig' calculates symbol values even before the conf_read() call. This is another issue that should be addressed separately, but it has revealed that the val_is_valid field is not initialized. Fixes: 95573cac25c6 ("kconfig: cache expression values") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-09-30kconfig: fix infinite loop in sym_calc_choice()Masahiro Yamada1-2/+8
Since commit f79dc03fe68c ("kconfig: refactor choice value calculation"), Kconfig for ARCH=powerpc may result in an infinite loop. This occurs because there are two entries for POWERPC64_CPU in a choice block. If the same symbol appears twice in a choice block, the ->choice_link node is added twice to ->choice_members, resulting a corrupted linked list. A simple test case is: choice prompt "choice" config A bool "A" config B bool "B 1" config B bool "B 2" endchoice Running 'make defconfig' results in an infinite loop. One solution is to replace the current two entries: config POWERPC64_CPU bool "Generic (POWER5 and PowerPC 970 and above)" depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN select PPC_64S_HASH_MMU config POWERPC64_CPU bool "Generic (POWER8 and above)" depends on PPC_BOOK3S_64 && CPU_LITTLE_ENDIAN select ARCH_HAS_FAST_MULTIPLIER select PPC_64S_HASH_MMU select PPC_HAS_LBARX_LHARX with the following single entry: config POWERPC64_CPU bool "Generic 64 bit powerpc" depends on PPC_BOOK3S_64 select ARCH_HAS_FAST_MULTIPLIER if CPU_LITTLE_ENDIAN select PPC_64S_HASH_MMU select PPC_HAS_LBARX_LHARX if CPU_LITTLE_ENDIAN In my opinion, the latter looks cleaner, but PowerPC maintainers may prefer to display different prompts depending on CPU_LITTLE_ENDIAN. For now, this commit fixes the issue in Kconfig, restoring the original behavior. I will reconsider whether such a use case is worth supporting. Fixes: f79dc03fe68c ("kconfig: refactor choice value calculation") Reported-by: Marco Bonelli <marco@mebeim.net> Closes: https://lore.kernel.org/all/1763151587.3581913.1727224126288@privateemail.com/ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-09-20kconfig: cache expression valuesMasahiro Yamada5-4/+39
Cache expression values to avoid recalculating them repeatedly. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-09-20kconfig: use hash table to reuse expressionsMasahiro Yamada4-277/+157
Currently, every expression in Kconfig files produces a new abstract syntax tree (AST), even if it is identical to a previously encountered one. Consider the following code: config FOO bool "FOO" depends on (A || B) && C config BAR bool "BAR" depends on (A || B) && C config BAZ bool "BAZ" depends on A || B The "depends on" lines are similar, but currently a separate AST is allocated for each one. The current data structure looks like this: FOO->dep ==> AND BAR->dep ==> AND BAZ->dep ==> OR / \ / \ / \ OR C OR C A B / \ / \ A B A B This is redundant; FOO->dep and BAR->dep have identical ASTs but different memory instances. We can optimize this; FOO->dep and BAR->dep can share the same AST, and BAZ->dep can reference its sub tree. The optimized data structure looks like this: FOO->dep, BAR->dep ==> AND / \ BAZ->dep ==> OR C / \ A B This commit introduces a hash table to keep track of allocated expressions. If an identical expression is found, it is reused. This does not necessarily result in memory savings, as menu_finalize() transforms expressions without freeing up stale ones. This will be addressed later. One optimization that can be easily implemented is caching the expression's value. Once FOO's dependency, (A || B) && C, is calculated, it can be cached, eliminating the need to recalculate it for BAR. This commit also reverts commit e983b7b17ad1 ("kconfig/menu.c: fix multiple references to expressions in menu_add_prop()"). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-09-20kconfig: refactor expr_eliminate_dups()Masahiro Yamada1-11/+3
Currently, expr_eliminate_dups() passes two identical pointers down to expr_eliminate_dups1(), which later skips processing identical leaves. This approach is somewhat tricky and, more importantly, it will not work with the refactoring made in the next commit. This commit slightly changes the recursion logic; it deduplicates both the left and right arms, and then passes them to expr_eliminate_dups1(). expr_eliminate_dups() should produce the same result. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-09-20kconfig: add comments to expression transformationsMasahiro Yamada1-6/+37
Provide explanations for complex transformations. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-09-20kconfig: change some expr_*() functions to boolMasahiro Yamada2-10/+11
This clarifies the behavior of these functions. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-09-20scripts: move hash function from scripts/kconfig/ to scripts/include/Masahiro Yamada3-14/+5
This function was originally added by commit 8af27e1dc4e4 ("fixdep: use hash table instead of a single array"). Move it to scripts/include/ so that other host programs can use it. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-09-01kbuild: split x*alloc() functions in kconfig to scripts/include/xalloc.hMasahiro Yamada13-54/+12
These functions will be useful for other host programs. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-09-01kconfig: remove P_SYMBOL propertyMasahiro Yamada4-8/+0
P_SYMBOL is a pseudo property that was previously used for data linking purposes. It is no longer used except for debug prints. Remove it. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-09-01kconfig: stop adding P_SYMBOL property to symbolsMasahiro Yamada1-3/+1
I believe its last usage was in the following code: if (prop == NULL) prop = stack->sym->prop; This code was previously used to print the file name and line number of associated symbols in sym_check_print_recursive(), which was removed by commit 9d0d26604657 ("kconfig: recursive checks drop file/lineno"). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-09-01kconfig: remove dummy assignments to cur_{filename,lineno}Masahiro Yamada1-8/+0
Since commit ca4c74ba306e ("kconfig: remove P_CHOICE property"), menu_finalize() no longer calls menu_add_symbol(). No function references cur_filename or cur_lineno after yyparse(). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-08-06scripts: kconfig: merge_config: config files: add a trailing newlineAnders Roxell1-0/+2
When merging files without trailing newlines at the end of the file, two config fragments end up at the same row if file1.config doens't have a trailing newline at the end of the file. file1.config "CONFIG_1=y" file2.config "CONFIG_2=y" ./scripts/kconfig/merge_config.sh -m .config file1.config file2.config This will generate a .config looking like this. cat .config ... CONFIG_1=yCONFIG_2=y" Making sure so we add a newline at the end of every config file that is passed into the script. Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-21kbuild: move some helper headers from scripts/kconfig/ to scripts/include/Masahiro Yamada13-395/+11
Move array_size.h, hashtable.h, list.h, list_types.h from scripts/kconfig/ to scripts/include/. These headers will be useful for other host programs. Remove scripts/mod/list.h. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-20kconfig: recursive checks drop file/linenoHONG Yifan2-48/+30
This prevents segfault when getting filename and lineno in recursive checks. If the following snippet is found in Kconfig: [Test code 1] config FOO bool depends on BAR select BAR ... without BAR defined; then there is a segfault. Kconfig:34:error: recursive dependency detected! Kconfig:34: symbol FOO depends on BAR make[4]: *** [scripts/kconfig/Makefile:85: allnoconfig] Segmentation fault This is because of the following. BAR is a fake entry created by sym_lookup() with prop being NULL. In the recursive check, there is a NULL check for prop to fall back to stack->sym->prop if stack->prop is NULL. However, in this case, stack->sym points to the fake BAR entry created by sym_lookup(), so prop is still NULL. prop was then referenced without additional NULL checks, causing segfault. As the previous email thread suggests, the file and lineno for select is also wrong: [Test code 2] config FOO bool config BAR bool config FOO bool "FOO" depends on BAR select BAR $ make defconfig *** Default configuration is based on 'x86_64_defconfig' Kconfig:1:error: recursive dependency detected! Kconfig:1: symbol FOO depends on BAR Kconfig:4: symbol BAR is selected by FOO [...] Kconfig:4 should be Kconfig:10. This patch deletes the wrong and segfault-prone filename/lineno inference completely. With this patch, Test code 1 yields: error: recursive dependency detected! symbol FOO depends on BAR symbol BAR is selected by FOO Signed-off-by: HONG Yifan <elsk@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-20kconfig: remove 'e1' and 'e2' macros from expression deduplicationMasahiro Yamada1-52/+42
I do not think the macros 'e1' and 'e2' are readable. The statement: e1 = expr_alloc_symbol(...); affects the caller's variable, but this is not sufficiently clear from the code. Remove the macros. No functional change intended. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-16kconfig: remove SYMBOL_CHOICEVAL flagMasahiro Yamada5-11/+8
This flag is unneeded because a choice member can be detected by other means. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-16kconfig: add const qualifiers to several function argumentsMasahiro Yamada8-36/+40
Clarify that the given structures are not modified. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-16kconfig: call expr_eliminate_yn() at least once in expr_eliminate_dups()Masahiro Yamada1-5/+2
Kconfig simplifies expressions, but redundant '&&' and '||' operators involving constant symbols 'y' and 'n' are sometimes trimmed and sometimes not. [Test Code] config DEP def_bool y config A bool "A" depends on DEP && y config B bool "B" depends on DEP && y && y [Result] $ make helpnewconfig [ snip ] ----- There is no help available for this option. Symbol: A [=n] Type : bool Defined at Kconfig:4 Prompt: A Depends on: DEP [=y] && y [=y] Location: -> A (A [=n]) ----- ----- There is no help available for this option. Symbol: B [=n] Type : bool Defined at Kconfig:8 Prompt: B Depends on: DEP [=y] Location: -> B (B [=n]) ----- The dependency for A, 'DEP && y', remains as-is, while that for B, 'DEP && y && y', has been reduced to 'DEP'. Currently, expr_eliminate_dups() calls expr_eliminate_yn() only when trans_count != 0, in other words, only when expr_eliminate_dups1() has trimmed at least one leaf. It fails to trim a single '&& y', etc. To fix this inconsistent behavior, expr_eliminate_yn() should be called at least once even if no leaf has been trimmed. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-15kconfig: refactor error messages in sym_check_print_recursive()Masahiro Yamada1-9/+9
Improve the error messages and clean up redundant code. [1] remove redundant next_sym->name checks If 'next_sym' is a choice, the first 'if' block is executed. In the subsequent 'else if' blocks, 'next_sym" is not a choice, hence next_sym->name is not NULL. [2] remove redundant sym->name checks A choice is never selected or implied by anyone because it has no name (it is syntactically impossible). If it is, sym->name is not NULL. [3] Show the location of choice instead of "<choice>" "part of choice <choice>" does not convey useful information. Since a choice has no name, it is more informative to display the file name and line number. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-15kconfig: improve error message for recursive dependency in choiceMasahiro Yamada1-6/+1
Kconfig detects recursive dependencies in a choice block, but the error message is unclear. [Test Code] choice prompt "choose" depends on A config A bool "A" config B bool "B" endchoice [Result] Kconfig:1:error: recursive dependency detected! Kconfig:1: choice <choice> contains symbol A Kconfig:5: symbol A is part of choice <choice> For a resolution refer to Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive dependency limitations" The phrase "contains symbol A" does not accurately describe the problem. The issue is that the choice depends on A, which is a member of itself. The first if-block does not print a sensible message. Remove it. This commit improves the error message to: Kconfig:1:error: recursive dependency detected! Kconfig:1: symbol <choice> symbol is visible depending on A Kconfig:5: symbol A is part of choice <choice> For a resolution refer to Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive dependency limitations" Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-15kconfig: improve error message for dependency between choice membersMasahiro Yamada1-1/+1
A choice member must not depend on another member within the same choice block. Kconfig detects this, but the error message is not sensible. [Test Code] choice prompt "choose" config A bool "A" depends on B config B bool "B" endchoice [Result] Kconfig:1:error: recursive dependency detected! Kconfig:1: choice <choice> contains symbol A Kconfig:4: symbol A is part of choice B Kconfig:8: symbol B is part of choice <choice> For a resolution refer to Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive dependency limitations" The phrase "part of choice B" is weird because B is not a choice block, but a choice member. To determine whether the current symbol is a part of a choice block, sym_is_choice(next_sym) must be checked. This commit improves the error message to: Kconfig:1:error: recursive dependency detected! Kconfig:1: choice <choice> contains symbol A Kconfig:4: symbol A symbol is visible depending on B Kconfig:8: symbol B is part of choice <choice> For a resolution refer to Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive dependency limitations" Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-15kconfig: fix conditional prompt behavior for choiceMasahiro Yamada2-36/+4
When a prompt is followed by "if <expr>", the symbol is configurable when the if-conditional evaluates to true. A typical usage is as follows: menuconfig BLOCK bool "Enable the block layer" if EXPERT default y When EXPERT=n, the prompt is hidden, but this config entry is still active, and BLOCK is set to its default value 'y'. When EXPERT=y, the prompt is shown, making BLOCK a user-configurable option. This usage is common throughout the kernel tree, but it has never worked within a choice block. [Test Code] config EXPERT bool "Allow expert users to modify more options" choice prompt "Choose" if EXPERT config A bool "A" config B bool "B" endchoice [Result] # CONFIG_EXPERT is not set When the prompt is hidden, the choice block should produce the default without asking for the user's preference. Hence, the output should be: # CONFIG_EXPERT is not set CONFIG_A=y # CONFIG_B is not set Removing unnecessary hacks fixes the issue. This commit also changes the behavior of 'select' by choice members. [Test Code 2] config MODULES def_bool y modules config DEP def_tristate m if DEP choice prompt "choose" config A bool "A" select C endchoice config B def_bool y select D endif config C tristate config D tristate The current output is as follows: CONFIG_MODULES=y CONFIG_DEP=m CONFIG_A=y CONFIG_B=y CONFIG_C=y CONFIG_D=m With this commit, the output will be changed as follows: CONFIG_MODULES=y CONFIG_DEP=m CONFIG_A=y CONFIG_B=y CONFIG_C=m CONFIG_D=m CONFIG_C will be changed to 'm' because 'select C' will inherit the dependency on DEP, which is 'm'. This change is aligned with the behavior of 'select' outside a choice block; 'select D' depends on DEP, therefore D is selected by (B && DEP). Note: With this commit, allmodconfig will set CONFIG_USB_ROLE_SWITCH to 'm' instead of 'y'. I did not see any build regression with this change. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-15kconfig: remove E_LIST expression typeMasahiro Yamada3-18/+2
E_LIST was preveously used to form an expression tree consisting of choice members. It is no longer used. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-15kconfig: remove P_CHOICE propertyMasahiro Yamada6-37/+3
P_CHOICE is a pseudo property used to link a choice with its members. There is no more code relying on this, except for some debug code. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-15kconfig: use sym_get_choice_menu() in sym_check_deps()Masahiro Yamada1-4/+4
Choices and their members are associated via the P_CHOICE property. Currently, prop_get_symbol(sym_get_choice_prop()) is used to obtain the choice of the given choice member. Replace it with sym_get_choice_menu(), which retrieves the choice without relying on P_CHOICE. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-15kconfig: use sym_get_choice_menu() in sym_check_choice_deps()Masahiro Yamada1-3/+7
Choices and their members are associated via the P_CHOICE property. Currently, prop_get_symbol(sym_get_choice_prop()) is used to obtain the choice of the given choice member. Replace it with sym_get_choice_menu(), which retrieves the choice without relying on P_CHOICE. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-15kconfig: use sym_get_choice_menu() in sym_check_print_recursive()Masahiro Yamada1-2/+4
Choices and their members are associated via the P_CHOICE property. Currently, prop_get_symbol(sym_get_choice_prop()) is used to obtain the choice of the given choice member. Replace it with sym_get_choice_menu(), which retrieves the choice without relying on P_CHOICE. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-15kconfig: remove expr_list_for_each_sym() macroMasahiro Yamada1-3/+0
All users of this macro have been converted. Remove it. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-15kconfig: use menu_list_for_each_sym() in sym_choice_default()Masahiro Yamada1-5/+4
Choices and their members are associated via the P_CHOICE property. Currently, sym_get_choice_prop() and expr_list_for_each_sym() are used to iterate on choice members. Replace them with menu_for_each_sub_entry(), which achieves the same without relying on P_CHOICE. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-15kconfig: change sym_choice_default() to take the choice menuMasahiro Yamada3-6/+6
Change the argument of sym_choice_default() to ease further cleanups. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-15kconfig: remove conf_unsaved in conf_read_simple()Masahiro Yamada1-3/+2
This variable is unnecessary. Call conf_set_changed(true) directly. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-15kconfig: remove sym_get_choice_value()Masahiro Yamada6-21/+11
sym_get_choice_value(menu->sym) is equivalent to sym_calc_choice(menu). Convert all call sites of sym_get_choice_value() and then remove it. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-15kconfig: refactor choice value calculationMasahiro Yamada7-197/+187
Handling choices has always been in a PITA in Kconfig. For example, fixes and reverts were repeated for randconfig with KCONFIG_ALLCONFIG: - 422c809f03f0 ("kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG") - 23a5dfdad22a ("Revert "kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG"") - 8357b48549e1 ("kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG") - 490f16171119 ("Revert "kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG"") As these commits pointed out, randconfig does not randomize choices when KCONFIG_ALLCONFIG is used. This issue still remains. [Test Case] choice prompt "choose" config A bool "A" config B bool "B" endchoice $ echo > all.config $ make KCONFIG_ALLCONFIG=1 randconfig The output is always as follows: CONFIG_A=y # CONFIG_B is not set Not only randconfig, but other all*config variants are also broken with KCONFIG_ALLCONFIG. With the same Kconfig, $ echo '# CONFIG_A is not set' > all.config $ make KCONFIG_ALLCONFIG=1 allyesconfig You will get this: CONFIG_A=y # CONFIG_B is not set This is incorrect because it does not respect all.config. The correct output should be: # CONFIG_A is not set CONFIG_B=y To handle user inputs more accurately, this commit refactors the code based on the following principles: - When a user value is given, Kconfig must set it immediately. Do not defer it by setting SYMBOL_NEED_SET_CHOICE_VALUES. - The SYMBOL_DEF_USER flag must not be cleared, unless a new config file is loaded. Kconfig must not forget user inputs. In addition, user values for choices must be managed with priority. If user inputs conflict within a choice block, the newest value wins. The values given by randconfig have lower priority than explicit user inputs. This commit implements it by using a linked list. Every time a choice block gets a new input, it is moved to the top of the list. Let me explain how it works. Let's say, we have a choice block that consists of five symbols: A, B, C, D, and E. Initially, the linked list looks like this: A(=?) --> B(=?) --> C(=?) --> D(=?) --> E(=?) Suppose randconfig is executed with the following KCONFIG_ALLCONFIG: CONFIG_C=y # CONFIG_A is not set CONFIG_D=y First, CONFIG_C=y is read. C is set to 'y' and moved to the top. C(=y) --> A(=?) --> B(=?) --> D(=?) --> E(=?) Next, '# CONFIG_A is not set' is read. A is set to 'n' and moved to the top. A(=n) --> C(=y) --> B(=?) --> D(=?) --> E(=?) Then, 'CONFIG_D=y' is read. D is set to 'y' and moved to the top. D(=y) --> A(=n) --> C(=y) --> B(=?) --> E(=?) Lastly, randconfig shuffles the order of the remaining symbols, resulting in: D(=y) --> A(=n) --> C(=y) --> B(=y) --> E(=y) or D(=y) --> A(=n) --> C(=y) --> E(=y) --> B(=y) When calculating the output, the linked list is traversed and the first visible symbol with 'y' is taken. In this case, it is D if visible. If D is hidden by 'depends on', the next node, A, is examined. Since it is already specified as 'n', it is skipped. Next, C is checked, and selected if it is visible. If C is also invisible, either B or E is chosen as a result of the randomization. If B and E are also invisible, the linked list is traversed in the reverse order, and the least prioritized 'n' symbol is chosen. It is A in this case. Now, Kconfig remembers all user values. This is a big difference from the previous implementation, where Kconfig would forget CONFIG_C=y when CONFIG_D=y appeared in the same input file. The new appaorch respects user-specified values as much as possible. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-12-25 21:15:55 +0300