kconfig: remove zconfprint()

Turn all warnings during parsing into hard errors.

Signed-off-by: Masahiro Yamada <[email protected]>

kconfig: remove support for "bool" prompt for choice entries

Since commit fde192511bdb ("kconfig: remove tristate choice support"),
all choice blocks are now boolean. There is no longer a need to sp

kconfig: remove support for "bool" prompt for choice entries

Since commit fde192511bdb ("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 <[email protected]>

show more ...

kconfig: fix infinite loop in sym_calc_choice()

Since commit f79dc03fe68c ("kconfig: refactor choice value calculation"),
Kconfig for ARCH=powerpc may result in an infinite loop. This occurs
because

kconfig: fix infinite loop in sym_calc_choice()

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 <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: split x*alloc() functions in kconfig to scripts/include/xalloc.h

These functions will be useful for other host programs.

Signed-off-by: Masahiro Yamada <[email protected]>

kconfig: remove P_SYMBOL property

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

kconfig: remove P_SYMBOL property

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 <[email protected]>

show more ...

kconfig: remove dummy assignments to cur_{filename,lineno}

Since commit ca4c74ba306e ("kconfig: remove P_CHOICE property"),
menu_finalize() no longer calls menu_add_symbol(). No function
references

kconfig: remove dummy assignments to cur_{filename,lineno}

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 <[email protected]>

show more ...

kconfig: add const qualifiers to several function arguments

Clarify that the given structures are not modified.

Signed-off-by: Masahiro Yamada <[email protected]>

kconfig: remove P_CHOICE property

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 Y

kconfig: remove P_CHOICE property

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 <[email protected]>

show more ...

kconfig: refactor choice value calculation

Handling choices has always been in a PITA in Kconfig.

For example, fixes and reverts were repeated for randconfig with
KCONFIG_ALLCONFIG:

- 422c809f03f

kconfig: refactor choice value calculation

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 <[email protected]>

show more ...

kconfig: remember the current choice while parsing the choice block

Instead of the boolean flag, it will be more useful to remember the
current choice being parsed.

Signed-off-by: Masahiro Yamada <

kconfig: remember the current choice while parsing the choice block

Instead of the boolean flag, it will be more useful to remember the
current choice being parsed.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: remove tristate choice support

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 s

kconfig: remove tristate choice support

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:

- df8df5e4bc37 ("usb: get rid of 'choice' for legacy gadget drivers")
- bfb57ef0544a ("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 fa64e5f6a35e ("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/[email protected]/T/#m0a1bb6992581462ceca861b409bb33cb8fd7dbae

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>

show more ...

kconfig: turn defaults and additional prompt for choice members into error

menu_finalize() warns default properties for choice members and prompts
outside the choice block. These should be hard erro

kconfig: turn defaults and additional prompt for choice members into error

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 <[email protected]>

show more ...

kconfig: turn missing prompt for choice members into error

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()

kconfig: turn missing prompt for choice members into error

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 <[email protected]>

show more ...

kconfig: remove SYMBOL_NO_WRITE flag

This flag is set to symbols that are not intended to be written
to the .config file.

Since commit b75b0a819af9 ("kconfig: change defconfig_list option to
enviro

kconfig: remove SYMBOL_NO_WRITE flag

This flag is set to symbols that are not intended to be written
to the .config file.

Since commit b75b0a819af9 ("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 <[email protected]>

show more ...

kconfig: remove 'optional' property support

The 'choice' statement is primarily used to exclusively select one
option, but the 'optional' property allows all entries to be disabled.

In the followin

kconfig: remove 'optional' property support

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 <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>

show more ...

kconfig: remove SYMBOL_CHOICE flag

All symbols except choices have a name.

Previously, choices were allowed to have a name, but commit c83f020973bc
("kconfig: remove named choice support") eliminat

kconfig: remove SYMBOL_CHOICE flag

All symbols except choices have a name.

Previously, choices were allowed to have a name, but commit c83f020973bc
("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 <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>

show more ...

kconfig: use menu_for_each_entry() to traverse menu tree

Use menu_for_each_entry() to traverse the menu tree instead of
implementing similar logic in each function.

Signed-off-by: Masahiro Yamada <

kconfig: use menu_for_each_entry() to traverse menu tree

Use menu_for_each_entry() to traverse the menu tree instead of
implementing similar logic in each function.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: do not reparent the menu inside a choice block

The boolean 'choice' is used to list exclusively selected config
options.

You must not add a dependency between choice members, because such

kconfig: do not reparent the menu inside a choice block

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 <[email protected]>

show more ...

kconfig: check prompt for choice while parsing

This can be checked on-the-fly.

Signed-off-by: Masahiro Yamada <[email protected]>

kconfig: remove named choice support

Commit 5a1aa8a1aff6 ("kconfig: add named choice group") did not provide
enough explanation regarding its benefits. A use case was found in
another project [1] so

kconfig: remove named choice support

Commit 5a1aa8a1aff6 ("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/[email protected]/

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>

show more ...

kconfig: use generic macros to implement symbol hashtable

Use helper macros in hashtable.h for generic hashtable implementation.

We can git rid of the hash head index of for_all_symbols().

Signed-

kconfig: use generic macros to implement symbol hashtable

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 <[email protected]>

show more ...

kconfig: print recursive dependency errors in the parsed order

for_all_symbols() iterates in the symbol hash table. The order of
iteration depends on the hash table implementation.

If you use it fo

kconfig: print recursive dependency errors in the parsed order

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 <[email protected]>

show more ...

kconfig: do not delay the cur_filename update

Currently, cur_filename is updated at the first token of each statement.
However, this seems unnecessary based on my understanding; the parser
can use t

kconfig: do not delay the cur_filename update

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 <[email protected]>

show more ...

kconfig: associate struct menu with file name directly

struct menu is linked to struct file for diagnostic purposes.
It is always used to retrieve the file name through menu->file->name.

Associate

kconfig: associate struct menu with file name directly

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 <[email protected]>

show more ...

kconfig: remove zconf_curname() and zconf_lineno()

Now zconf_curname() and zconf_lineno() are so simple that they just
return cur_filename, cur_lineno, respectively.

Remove these functions, and the

kconfig: remove zconf_curname() and zconf_lineno()

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 <[email protected]>

show more ...