2018-12-18 12:13:35 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2002 Roman Zippel <zippel@linux-m68k.org>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef EXPR_H
|
|
|
|
#define EXPR_H
|
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
2011-11-23 18:05:53 +00:00
|
|
|
#include <assert.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <stdio.h>
|
|
|
|
#ifndef __cplusplus
|
|
|
|
#include <stdbool.h>
|
|
|
|
#endif
|
|
|
|
|
2024-07-20 07:27:38 +00:00
|
|
|
#include <list_types.h>
|
2024-02-11 12:41:05 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
typedef enum tristate {
|
|
|
|
no, mod, yes
|
|
|
|
} tristate;
|
|
|
|
|
|
|
|
enum expr_type {
|
2015-06-15 12:00:21 +00:00
|
|
|
E_NONE, E_OR, E_AND, E_NOT,
|
|
|
|
E_EQUAL, E_UNEQUAL, E_LTH, E_LEQ, E_GTH, E_GEQ,
|
2024-06-18 10:35:31 +00:00
|
|
|
E_SYMBOL, E_RANGE
|
2005-04-16 22:20:36 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
union expr_data {
|
kconfig: use hash table to reuse expressions
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-08 12:43:20 +00:00
|
|
|
struct expr * const expr;
|
|
|
|
struct symbol * const sym;
|
|
|
|
void *_initdata;
|
2005-04-16 22:20:36 +00:00
|
|
|
};
|
|
|
|
|
kconfig: use hash table to reuse expressions
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-08 12:43:20 +00:00
|
|
|
/**
|
|
|
|
* struct expr - expression
|
|
|
|
*
|
|
|
|
* @node: link node for the hash table
|
|
|
|
* @type: expressoin type
|
2024-09-08 12:43:21 +00:00
|
|
|
* @val: calculated tristate value
|
|
|
|
* @val_is_valid: indicate whether the value is valid
|
kconfig: use hash table to reuse expressions
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-08 12:43:20 +00:00
|
|
|
* @left: left node
|
|
|
|
* @right: right node
|
|
|
|
*/
|
2005-04-16 22:20:36 +00:00
|
|
|
struct expr {
|
kconfig: use hash table to reuse expressions
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-08 12:43:20 +00:00
|
|
|
struct hlist_node node;
|
2005-04-16 22:20:36 +00:00
|
|
|
enum expr_type type;
|
2024-09-08 12:43:21 +00:00
|
|
|
tristate val;
|
|
|
|
bool val_is_valid;
|
2005-04-16 22:20:36 +00:00
|
|
|
union expr_data left, right;
|
|
|
|
};
|
|
|
|
|
2008-01-07 20:09:55 +00:00
|
|
|
#define EXPR_OR(dep1, dep2) (((dep1)>(dep2))?(dep1):(dep2))
|
|
|
|
#define EXPR_AND(dep1, dep2) (((dep1)<(dep2))?(dep1):(dep2))
|
|
|
|
#define EXPR_NOT(dep) (2-(dep))
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
struct expr_value {
|
|
|
|
struct expr *expr;
|
|
|
|
tristate tri;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct symbol_value {
|
|
|
|
void *val;
|
|
|
|
tristate tri;
|
|
|
|
};
|
|
|
|
|
|
|
|
enum symbol_type {
|
kconfig: remove S_OTHER symbol type and correct dependency tracking
The S_OTHER type could be set only when conf_read_simple() is reading
include/config/auto.conf file.
For example, CONFIG_FOO=y exists in include/config/auto.conf but it is
missing from the currently parsed Kconfig files, sym_lookup() allocates
a new symbol, and sets its type to S_OTHER.
Strangely, it will be set to S_STRING by conf_set_sym_val() a few lines
below while it is obviously bool or tristate type. On the other hand,
when CONFIG_BAR="bar" is being dropped from include/config/auto.conf,
its type remains S_OTHER. Because for_all_symbols() omits S_OTHER
symbols, conf_touch_deps() misses to touch include/config/bar.h
This behavior has been a pretty mystery for me, and digging the git
histroy did not help. At least, touching depfiles is broken for string
type symbols.
I removed S_OTHER entirely, and reimplemented it more simply.
If CONFIG_FOO was visible in the previous syncconfig, but is missing
now, what we want to do is quite simple; just call conf_touch_dep()
to touch include/config/foo.h instead of allocating a new symbol data.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-11-30 09:15:51 +00:00
|
|
|
S_UNKNOWN, S_BOOLEAN, S_TRISTATE, S_INT, S_HEX, S_STRING
|
2005-04-16 22:20:36 +00:00
|
|
|
};
|
|
|
|
|
2008-12-26 20:07:57 +00:00
|
|
|
/* enum values are used as index to symbol.def[] */
|
2006-06-09 05:12:41 +00:00
|
|
|
enum {
|
|
|
|
S_DEF_USER, /* main user value */
|
2008-12-26 20:07:57 +00:00
|
|
|
S_DEF_AUTO, /* values read from auto.conf */
|
|
|
|
S_DEF_DEF3, /* Reserved for UI usage */
|
|
|
|
S_DEF_DEF4, /* Reserved for UI usage */
|
|
|
|
S_DEF_COUNT
|
2006-06-09 05:12:41 +00:00
|
|
|
};
|
|
|
|
|
2017-10-04 05:48:14 +00:00
|
|
|
/*
|
|
|
|
* Represents a configuration symbol.
|
|
|
|
*
|
2024-04-22 16:10:54 +00:00
|
|
|
* Choices are represented as a special kind of symbol with null name.
|
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 <masahiroy@kernel.org>
2024-06-18 10:35:21 +00:00
|
|
|
*
|
|
|
|
* @choice_link: linked to menu::choice_members
|
2017-10-04 05:48:14 +00:00
|
|
|
*/
|
2005-04-16 22:20:36 +00:00
|
|
|
struct symbol {
|
2024-02-11 12:41:05 +00:00
|
|
|
/* link node for the hash table */
|
|
|
|
struct hlist_node node;
|
2017-10-04 05:48:14 +00:00
|
|
|
|
|
|
|
/* The name of the symbol, e.g. "FOO" for 'config FOO' */
|
2005-04-16 22:20:36 +00:00
|
|
|
char *name;
|
2017-10-04 05:48:14 +00:00
|
|
|
|
|
|
|
/* S_BOOLEAN, S_TRISTATE, ... */
|
2005-04-16 22:20:36 +00:00
|
|
|
enum symbol_type type;
|
2017-10-04 05:48:14 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The calculated value of the symbol. The SYMBOL_VALID bit is set in
|
|
|
|
* 'flags' when this is up to date. Note that this value might differ
|
|
|
|
* from the user value set in e.g. a .config file, due to visibility.
|
|
|
|
*/
|
2006-06-09 05:12:41 +00:00
|
|
|
struct symbol_value curr;
|
2017-10-04 05:48:14 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Values for the symbol provided from outside. def[S_DEF_USER] holds
|
|
|
|
* the .config value.
|
|
|
|
*/
|
2008-12-26 20:07:57 +00:00
|
|
|
struct symbol_value def[S_DEF_COUNT];
|
2017-10-04 05:48:14 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* An upper bound on the tristate value the user can set for the symbol
|
|
|
|
* if it is a boolean or tristate. Calculated from prompt dependencies,
|
|
|
|
* which also inherit dependencies from enclosing menus, choices, and
|
|
|
|
* ifs. If 'n', the user value will be ignored.
|
|
|
|
*
|
|
|
|
* Symbols lacking prompts always have visibility 'n'.
|
|
|
|
*/
|
2005-04-16 22:20:36 +00:00
|
|
|
tristate visible;
|
2017-10-04 05:48:14 +00:00
|
|
|
|
2024-03-03 04:00:33 +00:00
|
|
|
/* config entries associated with this symbol */
|
|
|
|
struct list_head menus;
|
|
|
|
|
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 <masahiroy@kernel.org>
2024-06-18 10:35:21 +00:00
|
|
|
struct list_head choice_link;
|
|
|
|
|
2017-10-04 05:48:14 +00:00
|
|
|
/* SYMBOL_* flags */
|
2005-04-16 22:20:36 +00:00
|
|
|
int flags;
|
2017-10-04 05:48:14 +00:00
|
|
|
|
|
|
|
/* List of properties. See prop_type. */
|
2005-04-16 22:20:36 +00:00
|
|
|
struct property *prop;
|
2017-10-04 05:48:14 +00:00
|
|
|
|
|
|
|
/* Dependencies from enclosing menus, choices, and ifs */
|
2010-06-08 16:25:57 +00:00
|
|
|
struct expr_value dir_dep;
|
2017-10-04 05:48:14 +00:00
|
|
|
|
|
|
|
/* Reverse dependencies through being selected by other symbols */
|
2005-04-16 22:20:36 +00:00
|
|
|
struct expr_value rev_dep;
|
2017-10-04 05:48:14 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* "Weak" reverse dependencies through being implied by other symbols
|
|
|
|
*/
|
2016-11-11 05:10:05 +00:00
|
|
|
struct expr_value implied;
|
2005-04-16 22:20:36 +00:00
|
|
|
};
|
|
|
|
|
2008-12-26 20:25:00 +00:00
|
|
|
#define SYMBOL_CONST 0x0001 /* symbol is const */
|
|
|
|
#define SYMBOL_CHECK 0x0008 /* used during dependency checking */
|
|
|
|
#define SYMBOL_VALID 0x0080 /* set when symbol.curr is calculated */
|
2013-10-03 15:21:23 +00:00
|
|
|
#define SYMBOL_WRITE 0x0200 /* write symbol to file (KCONFIG_CONFIG) */
|
kconfig: fix missing choice values in auto.conf
Since commit 00c864f8903d ("kconfig: allow all config targets to write
auto.conf if missing"), Kconfig creates include/config/auto.conf in the
defconfig stage when it is missing.
Joonas Kylmälä reported incorrect auto.conf generation under some
circumstances.
To reproduce it, apply the following diff:
| --- a/arch/arm/configs/imx_v6_v7_defconfig
| +++ b/arch/arm/configs/imx_v6_v7_defconfig
| @@ -345,14 +345,7 @@ CONFIG_USB_CONFIGFS_F_MIDI=y
| CONFIG_USB_CONFIGFS_F_HID=y
| CONFIG_USB_CONFIGFS_F_UVC=y
| CONFIG_USB_CONFIGFS_F_PRINTER=y
| -CONFIG_USB_ZERO=m
| -CONFIG_USB_AUDIO=m
| -CONFIG_USB_ETH=m
| -CONFIG_USB_G_NCM=m
| -CONFIG_USB_GADGETFS=m
| -CONFIG_USB_FUNCTIONFS=m
| -CONFIG_USB_MASS_STORAGE=m
| -CONFIG_USB_G_SERIAL=m
| +CONFIG_USB_FUNCTIONFS=y
| CONFIG_MMC=y
| CONFIG_MMC_SDHCI=y
| CONFIG_MMC_SDHCI_PLTFM=y
And then, run:
$ make ARCH=arm mrproper imx_v6_v7_defconfig
You will see CONFIG_USB_FUNCTIONFS=y is correctly contained in the
.config, but not in the auto.conf.
Please note drivers/usb/gadget/legacy/Kconfig is included from a choice
block in drivers/usb/gadget/Kconfig. So USB_FUNCTIONFS is a choice value.
This is probably a similar situation described in commit beaaddb62540
("kconfig: tests: test defconfig when two choices interact").
When sym_calc_choice() is called, the choice symbol forgets the
SYMBOL_DEF_USER unless all of its choice values are explicitly set by
the user.
The choice symbol is given just one chance to recall it because
set_all_choice_values() is called if SYMBOL_NEED_SET_CHOICE_VALUES
is set.
When sym_calc_choice() is called again, the choice symbol forgets it
forever, since SYMBOL_NEED_SET_CHOICE_VALUES is a one-time aid.
Hence, we cannot call sym_clear_all_valid() again and again.
It is crazy to repeat set and unset of internal flags. However, we
cannot simply get rid of "sym->flags &= flags | ~SYMBOL_DEF_USER;"
Doing so would re-introduce the problem solved by commit 5d09598d488f
("kconfig: fix new choices being skipped upon config update").
To work around the issue, conf_write_autoconf() stopped calling
sym_clear_all_valid().
conf_write() must be changed accordingly. Currently, it clears
SYMBOL_WRITE after the symbol is written into the .config file. This
is needed to prevent it from writing the same symbol multiple times in
case the symbol is declared in two or more locations. I added the new
flag SYMBOL_WRITTEN, to track the symbols that have been written.
Anyway, this is a cheesy workaround in order to suppress the issue
as far as defconfig is concerned.
Handling of choices is totally broken. sym_clear_all_valid() is called
every time a user touches a symbol from the GUI interface. To reproduce
it, just add a new symbol drivers/usb/gadget/legacy/Kconfig, then touch
around unrelated symbols from menuconfig. USB_FUNCTIONFS will disappear
from the .config file.
I added the Fixes tag since it is more fatal than before. But, this
has been broken since long long time before, and still it is.
We should take a closer look to fix this correctly somehow.
Fixes: 00c864f8903d ("kconfig: allow all config targets to write auto.conf if missing")
Cc: linux-stable <stable@vger.kernel.org> # 4.19+
Reported-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
2019-07-12 06:07:09 +00:00
|
|
|
#define SYMBOL_WRITTEN 0x0800 /* track info to avoid double-write to .config */
|
2008-12-26 20:25:00 +00:00
|
|
|
#define SYMBOL_CHECKED 0x2000 /* used during dependency checking */
|
|
|
|
#define SYMBOL_WARNED 0x8000 /* warning has been issued */
|
|
|
|
|
|
|
|
/* Set when symbol.def[] is used */
|
|
|
|
#define SYMBOL_DEF 0x10000 /* First bit of SYMBOL_DEF */
|
|
|
|
#define SYMBOL_DEF_USER 0x10000 /* symbol.def[S_DEF_USER] is valid */
|
|
|
|
#define SYMBOL_DEF_AUTO 0x20000 /* symbol.def[S_DEF_AUTO] is valid */
|
|
|
|
#define SYMBOL_DEF3 0x40000 /* symbol.def[S_DEF_3] is valid */
|
|
|
|
#define SYMBOL_DEF4 0x80000 /* symbol.def[S_DEF_4] is valid */
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
#define SYMBOL_MAXLENGTH 256
|
|
|
|
|
2008-12-26 20:32:31 +00:00
|
|
|
/* A property represent the config options that can be associated
|
|
|
|
* with a config "symbol".
|
|
|
|
* Sample:
|
|
|
|
* config FOO
|
|
|
|
* default y
|
|
|
|
* prompt "foo prompt"
|
|
|
|
* select BAR
|
|
|
|
* config BAZ
|
|
|
|
* int "BAZ Value"
|
|
|
|
* range 1..255
|
2018-06-22 19:27:38 +00:00
|
|
|
*
|
2019-01-24 10:47:30 +00:00
|
|
|
* Please, also check parser.y:print_symbol() when modifying the
|
2018-06-22 19:27:38 +00:00
|
|
|
* list of property types!
|
2008-12-26 20:32:31 +00:00
|
|
|
*/
|
2005-04-16 22:20:36 +00:00
|
|
|
enum prop_type {
|
2008-12-26 20:32:31 +00:00
|
|
|
P_UNKNOWN,
|
|
|
|
P_PROMPT, /* prompt "foo prompt" or "BAZ Value" */
|
|
|
|
P_COMMENT, /* text associated with a comment */
|
2017-10-04 05:48:14 +00:00
|
|
|
P_MENU, /* prompt associated with a menu or menuconfig symbol */
|
2008-12-26 20:32:31 +00:00
|
|
|
P_DEFAULT, /* default y */
|
|
|
|
P_SELECT, /* select BAR */
|
2016-11-11 05:10:05 +00:00
|
|
|
P_IMPLY, /* imply BAR */
|
2008-12-26 20:32:31 +00:00
|
|
|
P_RANGE, /* range 7..100 (for a symbol) */
|
2005-04-16 22:20:36 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct property {
|
2008-12-26 20:32:31 +00:00
|
|
|
struct property *next; /* next property - null if last */
|
|
|
|
enum prop_type type; /* type of property */
|
|
|
|
const char *text; /* the prompt value - P_PROMPT, P_MENU, P_COMMENT */
|
2005-04-16 22:20:36 +00:00
|
|
|
struct expr_value visible;
|
2008-12-26 20:32:31 +00:00
|
|
|
struct expr *expr; /* the optional conditional part of the property */
|
|
|
|
struct menu *menu; /* the menu the property are associated with
|
2024-06-18 10:35:30 +00:00
|
|
|
* valid for: P_SELECT, P_RANGE,
|
2008-12-26 20:32:31 +00:00
|
|
|
* P_PROMPT, P_DEFAULT, P_MENU, P_COMMENT */
|
2024-02-02 15:58:10 +00:00
|
|
|
const char *filename; /* what file was this property defined */
|
2008-12-26 20:32:31 +00:00
|
|
|
int lineno; /* what lineno was this property defined */
|
2005-04-16 22:20:36 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
#define for_all_properties(sym, st, tok) \
|
|
|
|
for (st = sym->prop; st; st = st->next) \
|
|
|
|
if (st->type == (tok))
|
|
|
|
#define for_all_defaults(sym, st) for_all_properties(sym, st, P_DEFAULT)
|
|
|
|
#define for_all_prompts(sym, st) \
|
|
|
|
for (st = sym->prop; st; st = st->next) \
|
|
|
|
if (st->text)
|
|
|
|
|
2017-10-04 03:37:12 +00:00
|
|
|
/*
|
|
|
|
* Represents a node in the menu tree, as seen in e.g. menuconfig (though used
|
|
|
|
* for all front ends). Each symbol, menu, etc. defined in the Kconfig files
|
|
|
|
* gets a node. A symbol defined in multiple locations gets one node at each
|
|
|
|
* location.
|
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 <masahiroy@kernel.org>
2024-06-18 10:35:21 +00:00
|
|
|
*
|
|
|
|
* @choice_members: list of choice members with priority.
|
2017-10-04 03:37:12 +00:00
|
|
|
*/
|
2005-04-16 22:20:36 +00:00
|
|
|
struct menu {
|
2017-10-04 03:37:12 +00:00
|
|
|
/* The next menu node at the same level */
|
2005-04-16 22:20:36 +00:00
|
|
|
struct menu *next;
|
2017-10-04 03:37:12 +00:00
|
|
|
|
|
|
|
/* The parent menu node, corresponding to e.g. a menu or choice */
|
2005-04-16 22:20:36 +00:00
|
|
|
struct menu *parent;
|
2017-10-04 03:37:12 +00:00
|
|
|
|
|
|
|
/* The first child menu node, for e.g. menus and choices */
|
2005-04-16 22:20:36 +00:00
|
|
|
struct menu *list;
|
2017-10-04 03:37:12 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The symbol associated with the menu node. Choices are implemented as
|
|
|
|
* a special kind of symbol. NULL for menus, comments, and ifs.
|
|
|
|
*/
|
2005-04-16 22:20:36 +00:00
|
|
|
struct symbol *sym;
|
2017-10-04 03:37:12 +00:00
|
|
|
|
2024-03-03 04:00:33 +00:00
|
|
|
struct list_head link; /* link to symbol::menus */
|
|
|
|
|
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 <masahiroy@kernel.org>
2024-06-18 10:35:21 +00:00
|
|
|
struct list_head choice_members;
|
|
|
|
|
2017-10-04 03:37:12 +00:00
|
|
|
/*
|
|
|
|
* The prompt associated with the node. This holds the prompt for a
|
|
|
|
* symbol as well as the text for a menu or comment, along with the
|
|
|
|
* type (P_PROMPT, P_MENU, etc.)
|
|
|
|
*/
|
2005-04-16 22:20:36 +00:00
|
|
|
struct property *prompt;
|
2017-10-04 03:37:12 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* 'visible if' dependencies. If more than one is given, they will be
|
|
|
|
* ANDed together.
|
|
|
|
*/
|
2010-11-06 21:30:23 +00:00
|
|
|
struct expr *visibility;
|
2017-10-04 03:37:12 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Ordinary dependencies from e.g. 'depends on' and 'if', ANDed
|
|
|
|
* together
|
|
|
|
*/
|
2005-04-16 22:20:36 +00:00
|
|
|
struct expr *dep;
|
2017-10-04 03:37:12 +00:00
|
|
|
|
|
|
|
/* MENU_* flags */
|
2005-04-16 22:20:36 +00:00
|
|
|
unsigned int flags;
|
2017-10-04 03:37:12 +00:00
|
|
|
|
|
|
|
/* Any help text associated with the node */
|
2007-07-20 22:00:36 +00:00
|
|
|
char *help;
|
2017-10-04 03:37:12 +00:00
|
|
|
|
|
|
|
/* The location where the menu node appears in the Kconfig files */
|
2024-02-02 15:58:09 +00:00
|
|
|
const char *filename;
|
2005-04-16 22:20:36 +00:00
|
|
|
int lineno;
|
2017-10-04 03:37:12 +00:00
|
|
|
|
|
|
|
/* For use by front ends that need to store auxiliary data */
|
2005-04-16 22:20:36 +00:00
|
|
|
void *data;
|
|
|
|
};
|
|
|
|
|
2017-10-04 03:37:12 +00:00
|
|
|
/*
|
|
|
|
* Set on a menu node when the corresponding symbol changes state in some way.
|
|
|
|
* Can be checked by front ends.
|
|
|
|
*/
|
2005-04-16 22:20:36 +00:00
|
|
|
#define MENU_CHANGED 0x0001
|
2017-10-04 03:37:12 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
#define MENU_ROOT 0x0002
|
|
|
|
|
2012-08-23 18:55:08 +00:00
|
|
|
struct jump_key {
|
2012-10-21 09:27:53 +00:00
|
|
|
struct list_head entries;
|
2012-08-23 18:55:08 +00:00
|
|
|
size_t offset;
|
|
|
|
struct menu *target;
|
|
|
|
};
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
extern struct symbol symbol_yes, symbol_no, symbol_mod;
|
|
|
|
extern struct symbol *modules_sym;
|
|
|
|
extern int cdebug;
|
|
|
|
struct expr *expr_alloc_symbol(struct symbol *sym);
|
|
|
|
struct expr *expr_alloc_one(enum expr_type type, struct expr *ce);
|
|
|
|
struct expr *expr_alloc_two(enum expr_type type, struct expr *e1, struct expr *e2);
|
|
|
|
struct expr *expr_alloc_comp(enum expr_type type, struct symbol *s1, struct symbol *s2);
|
|
|
|
struct expr *expr_alloc_and(struct expr *e1, struct expr *e2);
|
|
|
|
struct expr *expr_alloc_or(struct expr *e1, struct expr *e2);
|
|
|
|
void expr_eliminate_eq(struct expr **ep1, struct expr **ep2);
|
2024-09-08 12:43:17 +00:00
|
|
|
bool expr_eq(struct expr *e1, struct expr *e2);
|
2005-04-16 22:20:36 +00:00
|
|
|
tristate expr_calc_value(struct expr *e);
|
|
|
|
struct expr *expr_eliminate_dups(struct expr *e);
|
|
|
|
struct expr *expr_transform(struct expr *e);
|
2024-09-08 12:43:17 +00:00
|
|
|
bool expr_contains_symbol(struct expr *dep, struct symbol *sym);
|
2005-04-16 22:20:36 +00:00
|
|
|
bool expr_depends_symbol(struct expr *dep, struct symbol *sym);
|
|
|
|
struct expr *expr_trans_compare(struct expr *e, enum expr_type type, struct symbol *sym);
|
|
|
|
|
|
|
|
void expr_fprint(struct expr *e, FILE *out);
|
|
|
|
struct gstr; /* forward */
|
2024-07-07 15:38:05 +00:00
|
|
|
void expr_gstr_print(const struct expr *e, struct gstr *gs);
|
2018-02-24 15:24:18 +00:00
|
|
|
void expr_gstr_print_revdep(struct expr *e, struct gstr *gs,
|
|
|
|
tristate pr_type, const char *title);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2024-09-08 12:43:17 +00:00
|
|
|
static inline bool expr_is_yes(const struct expr *e)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
return !e || (e->type == E_SYMBOL && e->left.sym == &symbol_yes);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#endif /* EXPR_H */
|