In gconf, choice entries display the selected symbol in the 'Value'
column, but it is not updated when the selected symbol is changed.
Set the MENU_CHANGED flag, so it is updated.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
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>
bcmp() was removed in POSIX.1-2008.
This commit replaces bcmp() with memcmp(). This allows Kconfig to link
with C libraries that do not provide bcmp(), such as Android bionic
libc.
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Reported-by: Abhigyan Ghosh <zscript.team.zs@gmail.com>
[masahiro: update commit description]
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, menu->prompt->type is checked to distinguish "comment"
(P_COMMENT) and "menu" (P_MENU) entries from regular "config" entries.
This is odd because P_COMMENT and P_MENU are not properties.
This commit introduces menu type enum to distinguish menu types more
naturally.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
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>
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>
The string allocated in sym_warn_unmet_dep() is never freed, leading
to a memory leak when an unmet dependency is detected.
Fixes: f8f69dc0b4 ("kconfig: make unmet dependency warnings readable")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
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 b75b0a819a ("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: b75b0a819a ("kconfig: change defconfig_list option to environment variable")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
A QString constructed from a character literal of length 0, i.e. "", is not
"null" for historical reasons. This does not matter here so use the preferred
method isEmpty() instead.
Also directly construct empty QString objects instead of passing in an empty
character literal that has to be parsed into an empty object first.
Signed-off-by: Rolf Eike Beer <eb@emlix.com>
Link: https://doc.qt.io/qt-6/qstring.html#distinction-between-null-and-empty-strings
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
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>
The positional argument specifies the top-level Kconfig. Include this
information in the help message.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The P_MENU entries ("menu" and "menuconfig") are never displayed in
symbolMode.
The condition, list->mode == symbolMode, is never met here.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Most of the code in ConfigInfoView::clicked() is unnecessary.
There is no need to use the regular expression to search for a symbol.
Calling sym_find() is simpler and faster.
The hyperlink always begins with the "s" tag, and there is no other
tag used. Remove it.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Split out the code that retrieves the menu entry with a prompt, so it
can be reused in other functions.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The only functional tag is href="s<symbol_name>".
Commit c4f7398bee ("kconfig: qconf: make debug links work again")
changed prop->name to sym->name for this reference, but it missed to
change the tag "m" to "s".
This tag is not functional at all.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
When the ESC key is pressed, the parentSelected() signal is currently
emitted for singleMode, menuMode, and symbolMode.
However, parentSelected() signal is functional only for singleMode.
In menuMode, the signal is connected to the goBack() slot, but nothing
occurs because configList->rootEntry is always &rootmenu.
In symbolMode (in the right pane), the parentSelected() signal is not
connected to any slot.
This commit prevents the unnecessary emission of the parentSelected()
signal.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The " (NEW)" string should be displayed regardless of the visibility
of the associated menu.
The ConfigItem::visible member is not used for any other purpose.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
When a menu is selected in the split view, the right pane displays the
goParent button, but it is never functional.
This is unnecessary, as you can select a menu from the menu tree in the
left pane.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Commit a2574c12df ("kconfig: qconf: convert to Qt5 new signal/slot
connection syntax") converted most of the old string-based connections,
but one more instance still remains. Convert it to the new style.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The default value of the quitOnLastWindowClosed property is true.
Hence, the application implicitly quits when the last window is closed.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Since commit fde192511b ("kconfig: remove tristate choice support"),
choice members are always boolean. The type check is redundant.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Replace the hand crafted lookup table with a QHash. This has the nice benefit
that the added offsets can not get out of sync with the length of the
replacement strings.
Signed-off-by: Rolf Eike Beer <eb@emlix.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This renames "Load" to "Open" and switches Ctrl-L to Ctrl-O for the default
platforms. This may break the workflow for those used to it, but will make it
actually work for everyone else like me who would just expect the default
behavior. Add some more standard shortcuts where available. If they replace
the existing shortcuts they would have the same value in my case.
Signed-off-by: Rolf Eike Beer <eb@emlix.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This is the native type used by the file dialogs and avoids any hassle with
filename encoding when converting this back and forth to a character array.
Signed-off-by: Rolf Eike Beer <eb@emlix.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Ignore process select warnings for config entries that have a default
option. Some config entries have no prompt, and nothing selects them, but
these config options are okay because they have a default option.
Signed-off-by: David Hunter <david.hunter.linux@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Track default options on the second line. On the second line of some
config entries, default and dependency options sometimes appear. In those
instances, the state will be "NEW" and not "DEP".
Signed-off-by: David Hunter <david.hunter.linux@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Put in the dollar sign for the variable '$config'. That way, the debug
message has more meaning.
Signed-off-by: David Hunter <david.hunter.linux@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Add the ability to cycle through dialog buttons with the TAB key.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The ->addWidget() method re-parents the widget. The parent QWidget can
be specified directly in the constructor.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Rearrange the code to make the upcoming refactoring easier to understand.
No functional changes intended.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Since commit fde192511b ("kconfig: remove tristate choice support"),
all choice blocks are now boolean. There is no longer a need to specify
the choice type explicitly.
All "bool" prompts in choice entries have been converted to "prompt".
This commit removes support for the "bool" syntax in choice entries.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Since commit f79dc03fe6 ("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: f79dc03fe6 ("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>
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: c4f7398bee ("kconfig: qconf: make debug links work again")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The constructor of ConfigMainWindow() calls show*View(), which needs
to calculate symbol values. conf_read() must be called before that.
Fixes: 060e05c3b4 ("kconfig: qconf: remove initial call to conf_changed()")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Since commit 95573cac25 ("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: 95573cac25 ("kconfig: cache expression values")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Since commit f79dc03fe6 ("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: f79dc03fe6 ("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>
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 e983b7b17a ("kconfig/menu.c: fix
multiple references to expressions in menu_add_prop()").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
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>
This function was originally added by commit 8af27e1dc4 ("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>
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>
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 9d0d266046 ("kconfig: recursive checks drop file/lineno").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Since commit ca4c74ba30 ("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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Handling choices has always been in a PITA in Kconfig.
For example, fixes and reverts were repeated for randconfig with
KCONFIG_ALLCONFIG:
- 422c809f03 ("kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG")
- 23a5dfdad2 ("Revert "kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG"")
- 8357b48549 ("kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG")
- 490f161711 ("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>
Currently, sym_set_tristate_value() is used to set 'y' to a choice
member, which is confusing because it not only sets 'y' to the given
symbol but also tweaks flags of other symbols as a side effect.
Add a dedicated function for setting the value of the given choice.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The condition (t2 == 0) never becomes true because the zero value
(i.e., E_NONE) is only used as a dummy type for prevtoken. It can
be passed to t1, but not to t2.
The caller of this function only checks expr_compare_type() > 0.
Therefore, the distinction between 0 and -1 is unnecessary.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Set -e to make these scripts fail on the first error.
Set -u because these scripts are invoked by Makefile, and do not work
properly without necessary variables defined.
Both options are described in POSIX. [1]
[1]: https://pubs.opengroup.org/onlinepubs/009604499/utilities/set.html
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Reduce the indentation level by continue'ing the loop earlier
if (!sym || sym_is_choice(sym)).
No functional change intended.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
The outer switch statement can be avoided by continue'ing earlier the
loop when the symbol type is neither S_BOOLEAN nor S_TRISTATE.
Remove it to reduce the indentation level by one. In addition, avoid
the repetition of sym->def[S_DEF_USER].tri.
No functional change intended.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
I previously submitted a fix for a bug in the choice feature [1], where
I mentioned, "Another (much cleaner) approach would be to remove the
tristate choice support entirely".
There are more issues in the tristate choice feature. For example, you
can observe a couple of bugs in the following test code.
[Test Code]
config MODULES
def_bool y
modules
choice
prompt "tristate choice"
default A
config A
tristate "A"
config B
tristate "B"
endchoice
Bug 1: the 'default' property is not correctly processed
'make alldefconfig' produces:
CONFIG_MODULES=y
# CONFIG_A is not set
# CONFIG_B is not set
However, the correct output should be:
CONFIG_MODULES=y
CONFIG_A=y
# CONFIG_B is not set
The unit test file, scripts/kconfig/tests/choice/alldef_expected_config,
is wrong as well.
Bug 2: choice members never get 'y' with randconfig
For the test code above, the following combinations are possible:
A B
(1) y n
(2) n y
(3) m m
(4) m n
(5) n m
(6) n n
'make randconfig' never produces (1) or (2).
These bugs are fixable, but a more critical problem is the lack of a
sensible syntax to specify the default for the tristate choice.
The default for the choice must be one of the choice members, which
cannot specify any of the patterns (3) through (6) above.
In addition, I have never seen it being used in a useful way.
The following commits removed unnecessary use of tristate choices:
- df8df5e4bc ("usb: get rid of 'choice' for legacy gadget drivers")
- bfb57ef054 ("rapidio: remove choice for enumeration")
This commit removes the tristate choice support entirely, which allows
me to delete a lot of code, making further refactoring easier.
Note:
This includes the revert of commit fa64e5f6a3 ("kconfig/symbol.c:
handle choice_values that depend on 'm' symbols"). It was suspicious
because it did not address the root cause but introduced inconsistency
in visibility between choice members and other symbols.
[1]: https://lore.kernel.org/linux-kbuild/20240427104231.2728905-1-masahiroy@kernel.org/T/#m0a1bb6992581462ceca861b409bb33cb8fd7dbae
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Commit ee06a3ef7e ("kconfig: Update config changed flag before calling
callback") pointed out that conf_updated flag must be updated _before_
calling the callback, which needs to know the new value.
Given that, it makes sense to directly pass the new value to the
callback.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
If any CONFIG option is changed while loading the .config file,
conf_read() calls conf_set_changed(true) and then the conf_changed()
callback.
With conf_read() moved after window initialization, the explicit
conf_changed() call can be removed.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
expr_trans_bool() performs an incorrect transformation.
[Test Code]
config MODULES
def_bool y
modules
config A
def_bool y
select C if B != n
config B
def_tristate m
config C
tristate
[Result]
CONFIG_MODULES=y
CONFIG_A=y
CONFIG_B=m
CONFIG_C=m
This output is incorrect because CONFIG_C=y is expected.
Documentation/kbuild/kconfig-language.rst clearly explains the function
of the '!=' operator:
If the values of both symbols are equal, it returns 'n',
otherwise 'y'.
Therefore, the statement:
select C if B != n
should be equivalent to:
select C if y
Or, more simply:
select C
Hence, the symbol C should be selected by the value of A, which is 'y'.
However, expr_trans_bool() wrongly transforms it to:
select C if B
Therefore, the symbol C is selected by (A && B), which is 'm'.
The comment block of expr_trans_bool() correctly explains its intention:
* bool FOO!=n => FOO
^^^^
If FOO is bool, FOO!=n can be simplified into FOO. This is correct.
However, the actual code performs this transformation when FOO is
tristate:
if (e->left.sym->type == S_TRISTATE) {
^^^^^^^^^^
While it can be fixed to S_BOOLEAN, there is no point in doing so
because expr_tranform() already transforms FOO!=n to FOO when FOO is
bool. (see the "case E_UNEQUAL" part)
expr_trans_bool() is wrong and unnecessary.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Currently, the initial state of the "Save" button is always active.
If none of the CONFIG options are changed while loading the .config
file, the "Save" button should be greyed out.
This can be fixed by calling conf_read() after widget initialization.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This is a leftover from commit ce1fc9345a ("kconfig: do not clear
SYMBOL_DEF_USER when the value is out of range").
This code is now redundant because if a user-supplied value is out
of range, the value adjusted by sym_validate_range() differs, and
conf_unsaved has already been incremented a few lines above.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The check for 'sym1 == sym2' is redundant here because it has already
been done a few lines above:
if (sym1 != sym2)
return NULL;
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, comparisons to 'm' or 'n' result in incorrect output.
[Test Code]
config MODULES
def_bool y
modules
config A
def_tristate m
config B
def_bool A > n
CONFIG_B is unset, while CONFIG_B=y is expected.
The reason for the issue is because Kconfig compares the tristate values
as strings.
Currently, the .type fields in the constant symbol definitions,
symbol_{yes,mod,no} are unspecified, i.e., S_UNKNOWN.
When expr_calc_value() evaluates 'A > n', it checks the types of 'A' and
'n' to determine how to compare them.
The left-hand side, 'A', is a tristate symbol with a value of 'm', which
corresponds to a numeric value of 1. (Internally, 'y', 'm', and 'n' are
represented as 2, 1, and 0, respectively.)
The right-hand side, 'n', has an unknown type, so it is treated as the
string "n" during the comparison.
expr_calc_value() compares two values numerically only when both can
have numeric values. Otherwise, they are compared as strings.
symbol numeric value ASCII code
-------------------------------------
y 2 0x79
m 1 0x6d
n 0 0x6e
'm' is greater than 'n' if compared numerically (since 1 is greater
than 0), but smaller than 'n' if compared as strings (since the ASCII
code 0x6d is smaller than 0x6e).
Specifying .type=S_TRISTATE for symbol_{yes,mod,no} fixes the above
test code.
Doing so, however, would cause a regression to the following test code.
[Test Code 2]
config MODULES
def_bool n
modules
config A
def_tristate n
config B
def_bool A = m
You would get CONFIG_B=y, while CONFIG_B should not be set.
The reason is because sym_get_string_value() turns 'm' into 'n' when the
module feature is disabled. Consequently, expr_calc_value() evaluates
'A = n' instead of 'A = m'. This oddity has been hidden because the type
of 'm' was previously S_UNKNOWN instead of S_TRISTATE.
sym_get_string_value() should not tweak the string because the tristate
value has already been correctly calculated. There is no reason to
return the string "n" where its tristate value is mod.
Fixes: 31847b67be ("kconfig: allow use of relations other than (in)equality")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This has not been used since commit e911503085 ("Kconfig: Remove
bad inference rules expr_eliminate_dups2()").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
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>
Previously, optional bool choices met the following conditions
simultaneously:
- sym_is_choice(sym)
- sym_is_changeable(sym)
- type == S_BOOLEAN
It no longer occurs since 6a1215888e ("kconfig: remove 'optional'
property support"). Remove the dead code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This code previously displayed child symbols of the selected choice
member.
Since commit 7e3465f63a ("kconfig: do not reparent the menu inside
a choice block"), choice members never have child symbols, therefore
this is dead code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, bool choices have a checkbox, but tristate choices do not.
It is opposite.
Bool choices should not have a checkbox, as they are fixed to 'y' since
commit 6a1215888e ("kconfig: remove 'optional' property support").
Tristate choices, however, should have a checkbox to allow users to
toggle the value.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
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>
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>
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.
We can do this without relying on P_CHOICE by checking the parent in
the menu structure.
Introduce a new helper to retrieve the choice if the given symbol is a
choice member.
This is intended to replace prop_get_symbol(sym_get_choice_prop()) and
deprecate P_CHOICE eventually.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
menu_finalize() warns default properties for choice members and prompts
outside the choice block. These should be hard errors.
While I was here, I moved the checks to slim down menu_finalize().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Choice members must have a prompt; hence make it an error.
While I was here, I moved the check to the parser to slim down
_menu_finalize().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Following the approach employed in commit bedf923623 ("kconfig: use
linked list in get_symbol_str() to iterate over menus"), simplify the
iteration on the menus of the specified symbol.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
SYMBOL_CHANGED and MENU_CHANGED are used to update GUI frontends
when the symbol value is changed. These are used inconsistently:
SYMBOL_CHANGED in gconf.c and MENU_CHANGE in qconf.cc.
MENU_CHANGED works more properly when a symbol has multiple prompts
(although such code is not ideal).
[test code]
config FOO
bool "foo prompt 1"
config FOO
bool "foo prompt 2"
In gconfig, if one of the two checkboxes is clicked, only the first
one is toggled. In xconfig, the two checkboxes work in sync.
Replace SYMBOL_CHANGED in gconf.c with MENU_CHANGED to align with
the xconfig behavior.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Every time a config file is loaded (either by clicking the "Load" button
or selecting "File" -> "Load" from the menu), a new list is appended to
the pane.
The current tree needs to be cleared by calling gtk_tree_store_clear().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for
checked-in source files. It is merely a convention without any functional
difference. In fact, $(obj) and $(src) are exactly the same, as defined
in scripts/Makefile.build:
src := $(obj)
When the kernel is built in a separate output directory, $(src) does
not accurately reflect the source directory location. While Kbuild
resolves this discrepancy by specifying VPATH=$(srctree) to search for
source files, it does not cover all cases. For example, when adding a
header search path for local headers, -I$(srctree)/$(src) is typically
passed to the compiler.
This introduces inconsistency between upstream and downstream Makefiles
because $(src) is used instead of $(srctree)/$(src) for the latter.
To address this inconsistency, this commit changes the semantics of
$(src) so that it always points to the directory in the source tree.
Going forward, the variables used in Makefiles will have the following
meanings:
$(obj) - directory in the object tree
$(src) - directory in the source tree (changed by this commit)
$(objtree) - the top of the kernel object tree
$(srctree) - the top of the kernel source tree
Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced
with $(src).
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
This flag is set to symbols that are not intended to be written
to the .config file.
Since commit b75b0a819a ("kconfig: change defconfig_list option to
environment variable"), SYMBOL_NO_WRITE is only set to choices.
Therefore, (sym->flags & SYMBOL_NO_WRITE) is equivalent to
sym_is_choice(sym). This flag is no longer necessary.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The 'choice' statement is primarily used to exclusively select one
option, but the 'optional' property allows all entries to be disabled.
In the following example, both A and B can be disabled simultaneously:
choice
prompt "choose A, B, or nothing"
optional
config A
bool "A"
config B
bool "B"
endchoice
You can achieve the equivalent outcome by other means.
A common solution is to add another option to guard the choice block.
In the following example, you can set ENABLE_A_B_CHOICE=n to disable
the entire choice block:
choice
prompt "choose A or B"
depends on ENABLE_A_B_CHOICE
config A
bool "A"
config B
bool "B"
endchoice
Another approach is to insert one more entry:
choice
prompt "choose A, B, or disable both"
config A
bool "A"
config B
bool "B"
config DISABLE_A_AND_B
bool "choose this to disable both A and B"
endchoice
Some real examples are DEBUG_INFO_NONE, INITRAMFS_COMPRESSION_NONE,
LTO_NONE, etc.
The 'optional' property is even more unnecessary for a tristate choice.
Without the 'optional' property, you can disable A and B; you can set
'm' in the choice prompt, and disable A and B individually:
choice
prompt "choose one built-in or make them modular"
config A
tristate "A"
config B
tristate "B"
endchoice
In conclusion, the 'optional' property was unneeded.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
All symbols except choices have a name.
Previously, choices were allowed to have a name, but commit c83f020973
("kconfig: remove named choice support") eliminated that possibility.
Now, it is easy to distinguish choices from normal symbols; if the name
is NULL, it is a choice.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
All symbols except choices have a name.
child->sym->name never becomes NULL inside choice blocks.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Use menu_for_each_entry() to traverse the menu tree instead of
implementing similar logic in each function.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Several functions require traversing menu entries sequentially. This
commit introduces some helpers to simplify such operations.
The menu_next() function facilitates depth-first traversal:
1. Descend to the child level if the current menu has one
2. Move to the next sibling at the same level if available
3. Ascend to the parent level if there is no more child or sibling
The menu_for_each_sub_entry() macro iterates over all submenu entries
using depth-first traverse.
The menu_for_each_entry() macro is the same, but over all menu entries.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Fixed a typo in some variables where height was misspelled as heigth.
Signed-off-by: Isak Ellmer <isak01@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The boolean 'choice' is used to list exclusively selected config
options.
You must not add a dependency between choice members, because such a
dependency would create an invisible entry.
In the following test case, it is impossible to choose 'C'.
[Test Case 1]
choice
prompt "Choose one, but how to choose C?"
config A
bool "A"
config B
bool "B"
config C
bool "C"
depends on A
endchoice
Hence, Kconfig shows the following error message:
Kconfig:1:error: recursive dependency detected!
Kconfig:1: choice <choice> contains symbol C
Kconfig:10: symbol C is part of choice A
Kconfig:4: symbol A is part of choice <choice>
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"
However, Kconfig does not report anything for the following similar code:
[Test Case 2]
choice
prompt "Choose one, but how to choose B?"
config A
bool "A"
config B
bool "B"
depends on A
config C
bool "C"
endchoice
This is because menu_finalize() reparents the menu tree when an entry
depends on the preceding one.
With reparenting, the menu tree:
choice
|- A
|- B
\- C
... will be transformed into the following structure:
choice
|- A
| \- B
\- C
Consequently, Kconfig considers only 'A' and 'C' as choice members.
This behavior is awkward. The second test case should be an error too.
This commit stops reparenting inside a choice.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Commit c8fb7d7e48 ("kconfig: fix broken dependency in randconfig-
generated .config") fixed the issue, but I did not add a test case.
This commit adds a test case that emulates the reported situation.
The test would fail without c8fb7d7e48.
To handle the choice "choose X", FOO must be calculated beforehand.
FOO depends on A, which is a member of another choice "choose A or B".
Kconfig _temporarily_ assumes the value of A to proceed. The choice
"choose A or B" will be shuffled later, but the result may or may not
meet "FOO depends on A". Kconfig should invalidate the symbol values
and recompute them.
In the real example for ARCH=arm64, the choice "Instrumentation type"
needs the value of CPU_BIG_ENDIAN. The choice "Endianness" will be
shuffled later.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Since commit 3b9a19e089 ("kconfig: loop as long as we changed some
symbols in randconfig"), conf_set_all_new_symbols() is repeated until
there is no more choice left to be shuffled. The motivation was to
shuffle a choice nested in another choice.
Although commit 09d5873e4d ("kconfig: allow only 'config', 'comment',
and 'if' inside 'choice'") disallowed the nested choice structure,
we must still keep 3b9a19e089 because there are still cases where
conf_set_all_new_symbols() must iterate.
scripts/kconfig/tests/choice_randomize/Kconfig is the test case.
The second choice depends on 'B', which is the member of the first
choice.
With 3b9a19e089 reverted, we would never get the pattern specified by
scripts/kconfig/tests/choice_randomize/expected_config2.
A real example can be found in lib/Kconfig.debug. Without 3b9a19e089,
the randconfig would not shuffle the "Compressed Debug information"
choice, which depends on DEBUG_INFO, which is derived from another
choice "Debug information".
My goal is to refactor Kconfig so that randconfig will work more
simply, without using the loop.
For now, let's add a test case to ensure all dependent choices are
shuffled, as it is a somewhat tricky case for the current Kconfig.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
When the condition 'sym == NULL' is met, the code will reach the
'next_menu' label regardless of the return value from menu_is_visible().
menu_is_visible() calculates some symbol values as a side-effect, for
instance by calling expr_calc_value(menu->visibility), but all the
symbol values will be calculated eventually.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Remove inputbox_order, searchbox, searchbox_title, searchbox_border
because they are initialized, but not used anywhere.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
For MENUCONFIG_COLOR=blackbg, the text in inactive buttons is invisible
because both the foreground and background are black.
Change the foreground color to white and remove the highlighting.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Commit 5a1aa8a1af ("kconfig: add named choice group") did not provide
enough explanation regarding its benefits. A use case was found in
another project [1] sometime later, this feature has never been used in
the kernel.
[1]: https://lore.kernel.org/all/201012150034.01356.yann.morin.1998@anciens.enib.fr/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Currently, get_symbol_str() uses a tricky approach to traverse the
associated menus.
With relevant menus now linked to the symbol using a linked list,
use list_for_each_entry() for iterating on the menus.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Currently, there is no direct link from (struct symbol) to (struct menu).
It is still possible to access associated menus through the P_SYMBOL
property, because property::menu is the relevant menu entry, but it
results in complex code, as seen in get_symbol_str().
Use a linked list for simpler traversal of relevant menus.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
When a checklist is opened, the cursor is rendered in a wrong position
(after the last list element on the screen). You can observe it by
opening any checklist in menuconfig.
Added wmove() to set the cursor in the proper position, just like in
menubox.c. Removed wnoutrefresh(dialog) because dialog window has
already been updated in print_buttons(). Replaced wnoutrefresh(list) and
doupdate() calls with one wrefresh(list) call.
Signed-off-by: Matthew Bystrin <dev.mbstr@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Use helper macros in hashtable.h for generic hashtable implementation.
We can git rid of the hash head index of for_all_symbols().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
for_all_symbols() iterates in the symbol hash table. The order of
iteration depends on the hash table implementation.
If you use it for printing errors, they are shown in random order.
For example, the order of following test input and the corresponding
error do not match:
- scripts/kconfig/tests/err_recursive_dep/Kconfig
- scripts/kconfig/tests/err_recursive_dep/expected_stderr
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Do not feed back the choice type to choice values.
Each choice value should explicitly specify 'bool' or 'tristate',
as all the Kconfig files already do. If the type were missing,
"config symbol defined without type" would be shown.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, a linked list is used to keep track of all the Kconfig
files that have ever been parsed. Every time the "source" statement
is encountered, the linked list is traversed to check if the file has
been opened before. This prevents the same file from being recorded
in include/config/auto.conf.cmd again.
Given 1500+ Kconfig files parsed, a hashtable is now a more optimal
data structure.
By the way, you may wonder why we check this in the first place.
It matters only when the same file is included multiple times.
In old days, such a use case was forbidden, but commit f094f8a1b2
("kconfig: allow multiple inclusion of the same file") provided a bit
more flexibility. Of course, it is almost hypothetical...
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Remove the 'static' qualifier from strhash() so that it can be accessed
from other files. Move it to util.c, which is a more appropriate location.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
To use ARRAY_SIZE from other files, move it to its own header,
just like include/linux/array_size.h.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Update the existing macros and inline functions based on
include/linux/list.h.
The variable name '_new' can be reverted to 'new' because this header
is no longer included from the C++ file, scripts/kconfig/qconf.cc.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The struct list_head is often embedded in other structures, while other
code is used in C functions.
By separating struct list_head into its own header, other headers are no
longer required to include the entire list.h.
This is similar to the kernel space, where struct list_head is defined
in <linux/types.h> instead of <linux/list.h>.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, file_lookup() returns a pointer to (struct file), but the
callers use only file->name.
Make it return the ->name member directly.
This adjustment encapsulates struct file and file_list as internal
implementation.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
struct file has two link nodes, 'next' and 'parent'.
The former is used to link files in the 'file_list' linked list,
which manages the list of Kconfig files seen so far.
The latter is used to link files in the 'current_file' linked list,
which manages the inclusion ("source") tree.
The latter should be tracked together with the lexer state.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, cur_filename is updated at the first token of each statement.
However, this seems unnecessary based on my understanding; the parser
can use the same variable as the lexer tracks.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
struct property is linked to struct file for diagnostic purposes.
It is always used to retrieve the file name through prop->file->name.
Associate struct property with the file name directly.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
struct menu is linked to struct file for diagnostic purposes.
It is always used to retrieve the file name through menu->file->name.
Associate struct menu with the file name directly.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Now zconf_curname() and zconf_lineno() are so simple that they just
return cur_filename, cur_lineno, respectively.
Remove these functions, and then use cur_filename and cur_lineno
directly.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Replace current_pos with separate variables representing the file name
and the line number, respectively.
No functional change is intended.
By the way, you might wonder why the "<none>" fallback exists in
zconf_curname(). menu_add_symbol() saves the current file and the line
number. It is intended to be called only during the yyparse() time.
However, menu_finalize() calls it, where there is no file being parsed.
This is a long-standing hack that should be fixed later. I left a FIXME
comment.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
