2018-12-18 21:13:35 +09:00
// SPDX-License-Identifier: GPL-2.0
2005-04-16 15:20:36 -07:00
/*
* Copyright ( C ) 2002 Roman Zippel < zippel @ linux - m68k . org >
*/
# include <ctype.h>
2015-12-09 14:56:12 -08:00
# include <limits.h>
2006-04-18 22:21:53 -07:00
# include <stdio.h>
2008-01-09 16:36:19 +01:00
# include <stdlib.h>
2005-04-16 15:20:36 -07:00
# include <string.h>
# include <time.h>
2008-01-09 16:36:19 +01:00
# include <unistd.h>
2010-07-31 23:35:26 +02:00
# include <getopt.h>
2009-03-12 15:15:31 +01:00
# include <sys/time.h>
2013-04-13 22:49:13 +02:00
# include <errno.h>
2005-04-16 15:20:36 -07:00
2024-02-11 21:41:05 +09:00
# include "internal.h"
2005-04-16 15:20:36 -07:00
# include "lkc.h"
static void conf ( struct menu * menu ) ;
static void check_conf ( struct menu * menu ) ;
2010-07-31 23:35:26 +02:00
enum input_mode {
oldaskconfig ,
2018-03-01 15:34:37 +09:00
syncconfig ,
2010-07-31 23:35:26 +02:00
oldconfig ,
allnoconfig ,
allyesconfig ,
allmodconfig ,
2010-07-31 23:35:31 +02:00
alldefconfig ,
2010-07-31 23:35:26 +02:00
randconfig ,
defconfig ,
2010-07-31 23:35:34 +02:00
savedefconfig ,
2010-07-31 23:35:28 +02:00
listnewconfig ,
2019-11-04 17:10:08 -05:00
helpnewconfig ,
2012-09-01 01:05:17 +08:00
olddefconfig ,
2019-12-17 18:42:06 +09:00
yes2modconfig ,
mod2yesconfig ,
2021-10-17 19:43:13 +02:00
mod2noconfig ,
2018-01-11 22:39:39 +09:00
} ;
static enum input_mode input_mode = oldaskconfig ;
2021-03-14 04:48:25 +09:00
static int input_mode_opt ;
2005-04-16 15:20:36 -07:00
static int indent = 1 ;
2013-02-19 02:24:26 +02:00
static int tty_stdio ;
2008-09-29 05:27:10 +02:00
static int sync_kconfig ;
2005-04-16 15:20:36 -07:00
static int conf_cnt ;
2015-12-09 14:56:12 -08:00
static char line [ PATH_MAX ] ;
2005-04-16 15:20:36 -07:00
static struct menu * rootEntry ;
2009-07-12 16:11:48 +08:00
static void print_help ( struct menu * menu )
2007-07-21 00:00:36 +02:00
{
2009-07-12 16:11:48 +08:00
struct gstr help = str_new ( ) ;
menu_get_ext_help ( menu , & help ) ;
printf ( " \n %s \n " , str_get ( & help ) ) ;
str_free ( & help ) ;
2007-07-21 00:00:36 +02:00
}
2005-06-25 14:59:22 -07:00
static void strip ( char * str )
2005-04-16 15:20:36 -07:00
{
2005-06-25 14:59:22 -07:00
char * p = str ;
2005-04-16 15:20:36 -07:00
int l ;
while ( ( isspace ( * p ) ) )
p + + ;
l = strlen ( p ) ;
if ( p ! = str )
memmove ( str , p , l + 1 ) ;
if ( ! l )
return ;
p = str + l - 1 ;
while ( ( isspace ( * p ) ) )
* p - - = 0 ;
}
2018-01-11 22:39:40 +09:00
/* Helper function to facilitate fgets() by Jean Sacren. */
static void xfgets ( char * str , int size , FILE * in )
{
if ( ! fgets ( str , size , in ) )
fprintf ( stderr , " \n Error in reading or end of file. \n " ) ;
2018-02-08 14:56:40 +09:00
if ( ! tty_stdio )
printf ( " %s " , str ) ;
2018-01-11 22:39:40 +09:00
}
2021-03-14 04:48:24 +09:00
static void set_randconfig_seed ( void )
{
unsigned int seed ;
char * env ;
bool seed_set = false ;
env = getenv ( " KCONFIG_SEED " ) ;
if ( env & & * env ) {
char * endp ;
seed = strtol ( env , & endp , 0 ) ;
if ( * endp = = ' \0 ' )
seed_set = true ;
}
if ( ! seed_set ) {
struct timeval now ;
/*
* Use microseconds derived seed , compensate for systems where it may
* be zero .
*/
gettimeofday ( & now , NULL ) ;
seed = ( now . tv_sec + 1 ) * ( now . tv_usec + 1 ) ;
}
printf ( " KCONFIG_SEED=0x%X \n " , seed ) ;
srand ( seed ) ;
}
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 19:35:21 +09:00
/**
* randomize_choice_values - randomize choice block
*
* @ choice : menu entry for the choice
*/
static void randomize_choice_values ( struct menu * choice )
2021-03-14 04:48:30 +09:00
{
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 19:35:21 +09:00
struct menu * menu ;
int x ;
int cnt = 0 ;
2021-03-14 04:48:30 +09:00
/*
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 19:35:21 +09:00
* First , count the number of symbols to randomize . If sym_has_value ( )
* is true , it was specified by KCONFIG_ALLCONFIG . It needs to be
* respected .
2021-03-14 04:48:30 +09:00
*/
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 19:35:21 +09:00
menu_for_each_sub_entry ( menu , choice ) {
struct symbol * sym = menu - > sym ;
if ( sym & & ! sym_has_value ( sym ) )
cnt + + ;
}
while ( cnt > 0 ) {
x = rand ( ) % cnt ;
menu_for_each_sub_entry ( menu , choice ) {
struct symbol * sym = menu - > sym ;
if ( sym & & ! sym_has_value ( sym ) )
x - - ;
if ( x < 0 ) {
sym - > def [ S_DEF_USER ] . tri = yes ;
sym - > flags | = SYMBOL_DEF_USER ;
/*
* Move the selected item to the _tail_ because
* this needs to have a lower priority than the
* user input from KCONFIG_ALLCONFIG .
*/
list_move_tail ( & sym - > choice_link ,
& choice - > choice_members ) ;
break ;
}
2021-03-14 04:48:30 +09:00
}
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 19:35:21 +09:00
cnt - - ;
2021-03-14 04:48:30 +09:00
}
}
enum conf_def_mode {
def_default ,
def_yes ,
def_mod ,
def_no ,
def_random
} ;
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 19:35:21 +09:00
static void conf_set_all_new_symbols ( enum conf_def_mode mode )
2021-03-14 04:48:30 +09:00
{
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 19:35:21 +09:00
struct menu * menu ;
2024-02-11 21:41:05 +09:00
int cnt ;
2021-03-14 04:48:30 +09:00
/*
* can ' t go as the default in switch - case below , otherwise gcc whines
* about - Wmaybe - uninitialized
*/
int pby = 50 ; /* probability of bool = y */
int pty = 33 ; /* probability of tristate = y */
int ptm = 33 ; /* probability of tristate = m */
if ( mode = = def_random ) {
int n , p [ 3 ] ;
char * env = getenv ( " KCONFIG_PROBABILITY " ) ;
n = 0 ;
while ( env & & * env ) {
char * endp ;
int tmp = strtol ( env , & endp , 10 ) ;
if ( tmp > = 0 & & tmp < = 100 ) {
p [ n + + ] = tmp ;
} else {
errno = ERANGE ;
perror ( " KCONFIG_PROBABILITY " ) ;
exit ( 1 ) ;
}
env = ( * endp = = ' : ' ) ? endp + 1 : endp ;
if ( n > = 3 )
break ;
}
switch ( n ) {
case 1 :
pby = p [ 0 ] ;
ptm = pby / 2 ;
pty = pby - ptm ;
break ;
case 2 :
pty = p [ 0 ] ;
ptm = p [ 1 ] ;
pby = pty + ptm ;
break ;
case 3 :
pby = p [ 0 ] ;
pty = p [ 1 ] ;
ptm = p [ 2 ] ;
break ;
}
if ( pty + ptm > 100 ) {
errno = ERANGE ;
perror ( " KCONFIG_PROBABILITY " ) ;
exit ( 1 ) ;
}
}
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 19:35:21 +09:00
menu_for_each_entry ( menu ) {
struct symbol * sym = menu - > sym ;
2024-06-02 21:54:15 +09:00
tristate val ;
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 19:35:21 +09:00
if ( ! sym | | ! menu - > prompt | | sym_has_value ( sym ) | |
( sym - > type ! = S_BOOLEAN & & sym - > type ! = S_TRISTATE ) | |
sym_is_choice_value ( sym ) )
2021-03-14 04:48:30 +09:00
continue ;
2024-06-02 21:54:15 +09:00
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 19:35:21 +09:00
if ( sym_is_choice ( sym ) ) {
if ( mode = = def_random )
randomize_choice_values ( menu ) ;
continue ;
}
2024-06-02 21:54:15 +09:00
switch ( mode ) {
case def_yes :
val = yes ;
break ;
case def_mod :
val = mod ;
break ;
case def_no :
val = no ;
break ;
case def_random :
val = no ;
cnt = rand ( ) % 100 ;
if ( sym - > type = = S_TRISTATE ) {
if ( cnt < pty )
val = yes ;
else if ( cnt < pty + ptm )
val = mod ;
} else if ( cnt < pby ) {
val = yes ;
2021-03-14 04:48:30 +09:00
}
break ;
default :
2024-06-02 21:54:15 +09:00
continue ;
2021-03-14 04:48:30 +09:00
}
2024-06-02 21:54:15 +09:00
sym - > def [ S_DEF_USER ] . tri = val ;
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 19:35:21 +09:00
sym - > flags | = SYMBOL_DEF_USER ;
2021-03-14 04:48:30 +09:00
}
sym_clear_all_valid ( ) ;
}
2021-10-17 19:43:13 +02:00
static void conf_rewrite_tristates ( tristate old_val , tristate new_val )
2021-03-14 04:48:29 +09:00
{
struct symbol * sym ;
2024-02-11 21:41:05 +09:00
for_all_symbols ( sym ) {
2021-03-14 04:48:29 +09:00
if ( sym_get_type ( sym ) = = S_TRISTATE & &
sym - > def [ S_DEF_USER ] . tri = = old_val )
sym - > def [ S_DEF_USER ] . tri = new_val ;
}
sym_clear_all_valid ( ) ;
}
2007-08-30 05:06:17 +02:00
static int conf_askvalue ( struct symbol * sym , const char * def )
2005-04-16 15:20:36 -07:00
{
if ( ! sym_has_value ( sym ) )
2018-05-22 21:36:12 +02:00
printf ( " (NEW) " ) ;
2005-04-16 15:20:36 -07:00
line [ 0 ] = ' \n ' ;
line [ 1 ] = 0 ;
2019-07-04 12:50:41 +02:00
if ( ! sym_is_changeable ( sym ) ) {
2005-04-16 15:20:36 -07:00
printf ( " %s \n " , def ) ;
line [ 0 ] = ' \n ' ;
line [ 1 ] = 0 ;
2007-08-30 05:06:17 +02:00
return 0 ;
2005-04-16 15:20:36 -07:00
}
switch ( input_mode ) {
2010-07-31 23:35:26 +02:00
case oldconfig :
2018-03-01 15:34:37 +09:00
case syncconfig :
2005-04-16 15:20:36 -07:00
if ( sym_has_value ( sym ) ) {
printf ( " %s \n " , def ) ;
2007-08-30 05:06:17 +02:00
return 0 ;
2005-04-16 15:20:36 -07:00
}
2011-05-31 12:30:26 -04:00
/* fall through */
2021-02-21 18:26:23 +09:00
default :
2005-04-16 15:20:36 -07:00
fflush ( stdout ) ;
2015-12-09 14:56:12 -08:00
xfgets ( line , sizeof ( line ) , stdin ) ;
2005-04-16 15:20:36 -07:00
break ;
}
2007-08-30 05:06:17 +02:00
return 1 ;
2005-04-16 15:20:36 -07:00
}
2009-09-18 12:49:23 -07:00
static int conf_string ( struct menu * menu )
2005-04-16 15:20:36 -07:00
{
struct symbol * sym = menu - > sym ;
2007-07-21 00:00:36 +02:00
const char * def ;
2005-04-16 15:20:36 -07:00
while ( 1 ) {
2018-05-22 21:36:12 +02:00
printf ( " %*s%s " , indent - 1 , " " , menu - > prompt - > text ) ;
2005-04-16 15:20:36 -07:00
printf ( " (%s) " , sym - > name ) ;
def = sym_get_string_value ( sym ) ;
2021-02-15 19:15:09 +01:00
if ( def )
2005-04-16 15:20:36 -07:00
printf ( " [%s] " , def ) ;
2007-08-30 05:06:17 +02:00
if ( ! conf_askvalue ( sym , def ) )
return 0 ;
2005-04-16 15:20:36 -07:00
switch ( line [ 0 ] ) {
case ' \n ' :
break ;
case ' ? ' :
/* print help */
if ( line [ 1 ] = = ' \n ' ) {
2009-07-12 16:11:48 +08:00
print_help ( menu ) ;
2005-04-16 15:20:36 -07:00
def = NULL ;
break ;
}
2011-05-31 12:30:26 -04:00
/* fall through */
2005-04-16 15:20:36 -07:00
default :
line [ strlen ( line ) - 1 ] = 0 ;
def = line ;
}
if ( def & & sym_set_string_value ( sym , def ) )
return 0 ;
}
}
static int conf_sym ( struct menu * menu )
{
struct symbol * sym = menu - > sym ;
tristate oldval , newval ;
while ( 1 ) {
2018-05-22 21:36:12 +02:00
printf ( " %*s%s " , indent - 1 , " " , menu - > prompt - > text ) ;
2005-04-16 15:20:36 -07:00
if ( sym - > name )
printf ( " (%s) " , sym - > name ) ;
putchar ( ' [ ' ) ;
oldval = sym_get_tristate_value ( sym ) ;
switch ( oldval ) {
case no :
putchar ( ' N ' ) ;
break ;
case mod :
putchar ( ' M ' ) ;
break ;
case yes :
putchar ( ' Y ' ) ;
break ;
}
if ( oldval ! = no & & sym_tristate_within_range ( sym , no ) )
printf ( " /n " ) ;
if ( oldval ! = mod & & sym_tristate_within_range ( sym , mod ) )
printf ( " /m " ) ;
if ( oldval ! = yes & & sym_tristate_within_range ( sym , yes ) )
printf ( " /y " ) ;
2018-02-06 09:34:43 +09:00
printf ( " /?] " ) ;
2007-08-30 05:06:17 +02:00
if ( ! conf_askvalue ( sym , sym_get_string_value ( sym ) ) )
return 0 ;
2005-04-16 15:20:36 -07:00
strip ( line ) ;
switch ( line [ 0 ] ) {
case ' n ' :
case ' N ' :
newval = no ;
if ( ! line [ 1 ] | | ! strcmp ( & line [ 1 ] , " o " ) )
break ;
continue ;
case ' m ' :
case ' M ' :
newval = mod ;
if ( ! line [ 1 ] )
break ;
continue ;
case ' y ' :
case ' Y ' :
newval = yes ;
if ( ! line [ 1 ] | | ! strcmp ( & line [ 1 ] , " es " ) )
break ;
continue ;
case 0 :
newval = oldval ;
break ;
case ' ? ' :
goto help ;
default :
continue ;
}
if ( sym_set_tristate_value ( sym , newval ) )
return 0 ;
help :
2009-07-12 16:11:48 +08:00
print_help ( menu ) ;
2005-04-16 15:20:36 -07:00
}
}
2024-05-05 03:33:31 +09:00
static void conf_choice ( struct menu * menu )
2005-04-16 15:20:36 -07:00
{
2024-06-18 19:35:22 +09:00
struct symbol * def_sym ;
2005-04-16 15:20:36 -07:00
struct menu * child ;
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 19:35:21 +09:00
bool is_new = false ;
2005-04-16 15:20:36 -07:00
while ( 1 ) {
int cnt , def ;
2018-05-22 21:36:12 +02:00
printf ( " %*s%s \n " , indent - 1 , " " , menu_get_prompt ( menu ) ) ;
2024-06-18 19:35:22 +09:00
def_sym = sym_calc_choice ( menu ) ;
2005-04-16 15:20:36 -07:00
cnt = def = 0 ;
2006-04-09 17:26:39 +02:00
line [ 0 ] = 0 ;
2005-04-16 15:20:36 -07:00
for ( child = menu - > list ; child ; child = child - > next ) {
if ( ! menu_is_visible ( child ) )
continue ;
if ( ! child - > sym ) {
2018-05-22 21:36:12 +02:00
printf ( " %*c %s \n " , indent , ' * ' , menu_get_prompt ( child ) ) ;
2005-04-16 15:20:36 -07:00
continue ;
}
cnt + + ;
if ( child - > sym = = def_sym ) {
def = cnt ;
printf ( " %*c " , indent , ' > ' ) ;
} else
printf ( " %*c " , indent , ' ' ) ;
2024-04-21 20:13:02 +09:00
printf ( " %d. %s (%s) " , cnt , menu_get_prompt ( child ) ,
child - > sym - > 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 19:35:21 +09:00
if ( ! sym_has_value ( child - > sym ) ) {
is_new = true ;
2018-05-22 21:36:12 +02:00
printf ( " (NEW) " ) ;
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 19:35:21 +09:00
}
2005-04-16 15:20:36 -07:00
printf ( " \n " ) ;
}
2018-05-22 21:36:12 +02:00
printf ( " %*schoice " , indent - 1 , " " ) ;
2005-04-16 15:20:36 -07:00
if ( cnt = = 1 ) {
printf ( " [1]: 1 \n " ) ;
goto conf_childs ;
}
2018-02-06 09:34:43 +09:00
printf ( " [1-%d?]: " , cnt ) ;
2005-04-16 15:20:36 -07:00
switch ( input_mode ) {
2010-07-31 23:35:26 +02:00
case oldconfig :
2018-03-01 15:34:37 +09:00
case syncconfig :
2005-04-16 15:20:36 -07:00
if ( ! is_new ) {
cnt = def ;
printf ( " %d \n " , cnt ) ;
break ;
}
2011-05-31 12:30:26 -04:00
/* fall through */
2010-07-31 23:35:26 +02:00
case oldaskconfig :
2005-04-16 15:20:36 -07:00
fflush ( stdout ) ;
2015-12-09 14:56:12 -08:00
xfgets ( line , sizeof ( line ) , stdin ) ;
2005-04-16 15:20:36 -07:00
strip ( line ) ;
if ( line [ 0 ] = = ' ? ' ) {
2009-07-12 16:11:48 +08:00
print_help ( menu ) ;
2005-04-16 15:20:36 -07:00
continue ;
}
if ( ! line [ 0 ] )
cnt = def ;
else if ( isdigit ( line [ 0 ] ) )
cnt = atoi ( line ) ;
else
continue ;
break ;
2008-06-30 22:45:38 +02:00
default :
break ;
2005-04-16 15:20:36 -07:00
}
conf_childs :
for ( child = menu - > list ; child ; child = child - > next ) {
if ( ! child - > sym | | ! menu_is_visible ( child ) )
continue ;
if ( ! - - cnt )
break ;
}
if ( ! child )
continue ;
2011-04-23 18:42:56 +01:00
if ( line [ 0 ] & & line [ strlen ( line ) - 1 ] = = ' ? ' ) {
2009-07-12 16:11:48 +08:00
print_help ( child ) ;
2005-04-16 15:20:36 -07:00
continue ;
}
2024-06-12 02:55:12 +09:00
choice_set_value ( menu , child - > sym ) ;
2024-05-05 03:33:31 +09:00
return ;
2005-04-16 15:20:36 -07:00
}
}
static void conf ( struct menu * menu )
{
struct symbol * sym ;
struct property * prop ;
struct menu * child ;
if ( ! menu_is_visible ( menu ) )
return ;
sym = menu - > sym ;
prop = menu - > prompt ;
if ( prop ) {
const char * prompt ;
switch ( prop - > type ) {
case P_MENU :
kconfig: hide irrelevant sub-menus for oldconfig
Historically, "make oldconfig" has changed its behavior several times,
quieter or louder. (I attached the history below.) Currently, it is
not as quiet as it should be. This commit addresses it.
Test Case
---------
---------------------------(Kconfig)----------------------------
menu "menu"
config FOO
bool "foo"
menu "sub menu"
config BAR
bool "bar"
endmenu
endmenu
menu "sibling menu"
config BAZ
bool "baz"
endmenu
----------------------------------------------------------------
---------------------------(.config)----------------------------
CONFIG_BAR=y
CONFIG_BAZ=y
----------------------------------------------------------------
With the Kconfig and .config above, "make silentoldconfig" and
"make oldconfig" work differently, like follows:
$ make silentoldconfig
scripts/kconfig/conf --silentoldconfig Kconfig
*
* Restart config...
*
*
* menu
*
foo (FOO) [N/y/?] (NEW) y
#
# configuration written to .config
#
$ make oldconfig
scripts/kconfig/conf --oldconfig Kconfig
*
* Restart config...
*
*
* menu
*
foo (FOO) [N/y/?] (NEW) y
*
* sub menu
*
bar (BAR) [Y/n/?] y
#
# configuration written to .config
#
Both hide "sibling node" since it is irrelevant. The difference is
that silentoldconfig hides "sub menu" whereas oldconfig does not.
The behavior of silentoldconfig is preferred since the "sub menu"
does not contain any new symbol.
The root cause is in conf(). There are three input modes that can
call conf(); oldaskconfig, oldconfig, and silentoldconfig.
Everytime conf() encounters a menu entry, it calls check_conf() to
check if it contains new symbols. If no new symbol is found, the
menu is just skipped.
Currently, this happens only when input_mode == silentoldconfig.
The oldaskconfig enters into the check_conf() loop as silentoldconfig,
so oldaskconfig works likewise for the second loop or later, but it
never happens for oldconfig. So, irrelevant sub-menus are shown for
oldconfig.
Change the test condition to "input_mode != oldaskconfig". This is
false only for the first loop of oldaskconfig; it must ask the user
all symbols, so no need to call check_conf().
History of oldconfig
--------------------
[0] Originally, "make oldconfig" was as loud as "make config" (It
showed the entire .config file)
[1] Commit cd9140e1e73a ("kconfig: make oldconfig is now less chatty")
made oldconfig quieter, but it was still less quieter than
silentoldconfig. (oldconfig did not hide sub-menus)
[2] Commit 204c96f60904 ("kconfig: fix silentoldconfig") changed
the input_mode of oldconfig to "ask_silent" from "ask_new".
So, oldconfig really became as quiet as silentoldconfig.
(oldconfig hided irrelevant sub-menus)
[3] Commit 4062f1a4c030 ("kconfig: use long options in conf") made
oldconfig as loud as [0] due to misconversion.
[4] Commit 14828349719a ("kconfig: fix make oldconfig") addressed
the misconversion of [3], but it made oldconfig quieter only to
the same level as [1], not [2].
This commit is restoring the behavior of [2].
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-02-28 09:15:24 +09:00
/*
* Except in oldaskconfig mode , we show only menus that
* contain new symbols .
*/
if ( input_mode ! = oldaskconfig & & rootEntry ! = menu ) {
2005-04-16 15:20:36 -07:00
check_conf ( menu ) ;
return ;
}
2011-05-31 12:30:26 -04:00
/* fall through */
2005-04-16 15:20:36 -07:00
case P_COMMENT :
prompt = menu_get_prompt ( menu ) ;
if ( prompt )
printf ( " %*c \n %*c %s \n %*c \n " ,
indent , ' * ' ,
2018-05-22 21:36:12 +02:00
indent , ' * ' , prompt ,
2005-04-16 15:20:36 -07:00
indent , ' * ' ) ;
default :
;
}
}
if ( ! sym )
goto conf_childs ;
if ( sym_is_choice ( sym ) ) {
conf_choice ( menu ) ;
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/20240427104231.2728905-1-masahiroy@kernel.org/T/#m0a1bb6992581462ceca861b409bb33cb8fd7dbae
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-06-02 21:54:14 +09:00
return ;
2005-04-16 15:20:36 -07:00
}
switch ( sym - > type ) {
case S_INT :
case S_HEX :
case S_STRING :
conf_string ( menu ) ;
break ;
default :
conf_sym ( menu ) ;
break ;
}
conf_childs :
if ( sym )
indent + = 2 ;
for ( child = menu - > list ; child ; child = child - > next )
conf ( child ) ;
if ( sym )
indent - = 2 ;
}
static void check_conf ( struct menu * menu )
{
struct symbol * sym ;
struct menu * child ;
if ( ! menu_is_visible ( menu ) )
return ;
sym = menu - > sym ;
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 19:35:21 +09:00
if ( sym & & ! sym_has_value ( sym ) & & sym_is_changeable ( sym ) ) {
2021-02-21 18:26:22 +09:00
switch ( input_mode ) {
case listnewconfig :
2021-10-01 14:32:47 +09:00
if ( sym - > name )
print_symbol_for_listconfig ( sym ) ;
2021-02-21 18:26:22 +09:00
break ;
case helpnewconfig :
printf ( " ----- \n " ) ;
print_help ( menu ) ;
printf ( " ----- \n " ) ;
break ;
default :
if ( ! conf_cnt + + )
printf ( " * \n * Restart config... \n * \n " ) ;
rootEntry = menu_get_parent_menu ( menu ) ;
conf ( rootEntry ) ;
break ;
2005-04-16 15:20:36 -07:00
}
}
for ( child = menu - > list ; child ; child = child - > next )
check_conf ( child ) ;
}
2021-05-29 02:13:21 +09:00
static const struct option long_opts [ ] = {
2021-03-14 04:48:26 +09:00
{ " help " , no_argument , NULL , ' h ' } ,
{ " silent " , no_argument , NULL , ' s ' } ,
2021-03-14 04:48:25 +09:00
{ " oldaskconfig " , no_argument , & input_mode_opt , oldaskconfig } ,
{ " oldconfig " , no_argument , & input_mode_opt , oldconfig } ,
{ " syncconfig " , no_argument , & input_mode_opt , syncconfig } ,
{ " defconfig " , required_argument , & input_mode_opt , defconfig } ,
{ " savedefconfig " , required_argument , & input_mode_opt , savedefconfig } ,
{ " allnoconfig " , no_argument , & input_mode_opt , allnoconfig } ,
{ " allyesconfig " , no_argument , & input_mode_opt , allyesconfig } ,
{ " allmodconfig " , no_argument , & input_mode_opt , allmodconfig } ,
{ " alldefconfig " , no_argument , & input_mode_opt , alldefconfig } ,
{ " randconfig " , no_argument , & input_mode_opt , randconfig } ,
{ " listnewconfig " , no_argument , & input_mode_opt , listnewconfig } ,
{ " helpnewconfig " , no_argument , & input_mode_opt , helpnewconfig } ,
{ " olddefconfig " , no_argument , & input_mode_opt , olddefconfig } ,
{ " yes2modconfig " , no_argument , & input_mode_opt , yes2modconfig } ,
{ " mod2yesconfig " , no_argument , & input_mode_opt , mod2yesconfig } ,
2021-10-17 19:43:13 +02:00
{ " mod2noconfig " , no_argument , & input_mode_opt , mod2noconfig } ,
2010-07-31 23:35:26 +02:00
{ NULL , 0 , NULL , 0 }
} ;
2010-11-02 00:26:33 -04:00
static void conf_usage ( const char * progname )
{
2021-03-14 04:48:27 +09:00
printf ( " Usage: %s [options] <kconfig-file> \n " , progname ) ;
printf ( " \n " ) ;
printf ( " Generic options: \n " ) ;
printf ( " -h, --help Print this message and exit. \n " ) ;
printf ( " -s, --silent Do not print log. \n " ) ;
printf ( " \n " ) ;
printf ( " Mode options: \n " ) ;
2010-11-02 00:26:33 -04:00
printf ( " --listnewconfig List new options \n " ) ;
2019-11-04 17:10:08 -05:00
printf ( " --helpnewconfig List new options and help text \n " ) ;
2010-11-02 00:26:33 -04:00
printf ( " --oldaskconfig Start a new configuration using a line-oriented program \n " ) ;
printf ( " --oldconfig Update a configuration using a provided .config as base \n " ) ;
2018-03-01 15:34:37 +09:00
printf ( " --syncconfig Similar to oldconfig but generates configuration in \n "
" include/{generated/,config/} \n " ) ;
2018-01-26 14:59:00 -08:00
printf ( " --olddefconfig Same as oldconfig but sets new symbols to their default value \n " ) ;
2010-11-02 00:26:33 -04:00
printf ( " --defconfig <file> New config with default defined in <file> \n " ) ;
printf ( " --savedefconfig <file> Save the minimal current configuration to <file> \n " ) ;
printf ( " --allnoconfig New config where all options are answered with no \n " ) ;
printf ( " --allyesconfig New config where all options are answered with yes \n " ) ;
printf ( " --allmodconfig New config where all options are answered with mod \n " ) ;
printf ( " --alldefconfig New config with all symbols set to default \n " ) ;
printf ( " --randconfig New config with random answer to all options \n " ) ;
2019-12-17 18:42:06 +09:00
printf ( " --yes2modconfig Change answers from yes to mod if possible \n " ) ;
printf ( " --mod2yesconfig Change answers from mod to yes if possible \n " ) ;
2021-10-17 19:43:13 +02:00
printf ( " --mod2noconfig Change answers from mod to no if possible \n " ) ;
2021-02-21 22:03:17 +09:00
printf ( " (If none of the above is given, --oldaskconfig is the default) \n " ) ;
2010-11-02 00:26:33 -04:00
}
2005-04-16 15:20:36 -07:00
int main ( int ac , char * * av )
{
2010-11-02 00:26:33 -04:00
const char * progname = av [ 0 ] ;
2007-12-17 01:34:58 -05:00
int opt ;
2010-10-13 20:43:28 -04:00
const char * name , * defconfig_file = NULL /* gcc uninit */ ;
kconfig: make syncconfig update .config regardless of sym_change_count
syncconfig updates the .config only when sym_change_count > 0, i.e.
any change in config symbols has been detected.
Not only symbols but also comments are contained in the .config file.
If only comments are updated, they are not fed back to the .config,
then the stale comments are left-over. Of course, this is just a
matter of comments, but why not fix it.
I see some scenarios where this happens.
Scenario A:
1. You have a source tree that has already been configured.
2. Linus increments the version number in the top-level Makefile
(i.e. he commits a new release)
3. You pull it, and run 'make'
4. syncconfig is invoked because the environment variable,
KERNELVERSION is updated, but the .config is not updated since
no config symbol is changed.
5. The .config file contains a kernel version in the top line:
# Automatically generated file; DO NOT EDIT.
# Linux/arm64 4.18.0-rc2 Kernel Configuration
... which points to a previous version.
Scenario B:
1. You have a source tree that has already been configured.
2. You upgrade the compiler, but it still has the same version number.
This may happen if you regularly build the latest compiler from
the source code.
3. You run 'make'
4. syncconfig is invoked because the environment variable,
CC_VERSION_TEXT is updated, but the .config is not updated since
no config symbol is changed.
5. The .config file contains the version string of the compiler:
#
# Compiler: aarch64-linux-gcc (GCC) 9.0.0 20180628 (experimental)
#
... which carries the information of the old compiler.
If KCONFIG_NOSILENTUPDATE is set, syncconfig is not allowed to update
the .config file. Otherwise, it is fine to update it regardless of
sym_change_count.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-20 16:46:30 +09:00
int no_conf_write = 0 ;
2005-04-16 15:20:36 -07:00
2018-02-08 14:56:40 +09:00
tty_stdio = isatty ( 0 ) & & isatty ( 1 ) ;
2013-02-19 02:24:26 +02:00
2021-02-21 22:03:16 +09:00
while ( ( opt = getopt_long ( ac , av , " hs " , long_opts , NULL ) ) ! = - 1 ) {
2007-12-17 01:34:58 -05:00
switch ( opt ) {
2021-02-21 22:03:16 +09:00
case ' h ' :
2010-11-02 00:26:33 -04:00
conf_usage ( progname ) ;
2007-12-17 01:34:58 -05:00
exit ( 1 ) ;
2010-07-31 23:35:26 +02:00
break ;
2021-03-14 04:48:25 +09:00
case ' s ' :
conf_set_message_callback ( NULL ) ;
break ;
case 0 :
input_mode = input_mode_opt ;
switch ( input_mode ) {
case syncconfig :
/*
* syncconfig is invoked during the build stage .
* Suppress distracting
* " configuration written to ... "
*/
conf_set_message_callback ( NULL ) ;
sync_kconfig = 1 ;
break ;
case defconfig :
case savedefconfig :
defconfig_file = optarg ;
break ;
case randconfig :
set_randconfig_seed ( ) ;
break ;
default :
break ;
}
default :
break ;
2005-04-16 15:20:36 -07:00
}
}
2007-12-17 01:34:58 -05:00
if ( ac = = optind ) {
2018-05-22 21:36:12 +02:00
fprintf ( stderr , " %s: Kconfig file missing \n " , av [ 0 ] ) ;
2010-11-02 00:26:33 -04:00
conf_usage ( progname ) ;
2006-06-08 22:12:50 -07:00
exit ( 1 ) ;
2005-04-16 15:20:36 -07:00
}
2021-03-14 04:48:28 +09:00
conf_parse ( av [ optind ] ) ;
2005-04-16 15:20:36 -07:00
//zconfdump(stdout);
2008-09-29 05:27:10 +02:00
2005-04-16 15:20:36 -07:00
switch ( input_mode ) {
2010-07-31 23:35:26 +02:00
case defconfig :
2005-04-16 15:20:36 -07:00
if ( conf_read ( defconfig_file ) ) {
2018-02-06 09:34:41 +09:00
fprintf ( stderr ,
2018-05-22 21:36:12 +02:00
" *** \n "
2018-02-06 09:34:41 +09:00
" *** Can't find default configuration \" %s \" ! \n "
2018-05-22 21:36:12 +02:00
" *** \n " ,
2018-02-06 09:34:41 +09:00
defconfig_file ) ;
2005-04-16 15:20:36 -07:00
exit ( 1 ) ;
}
break ;
2010-07-31 23:35:34 +02:00
case savedefconfig :
2018-03-01 15:34:37 +09:00
case syncconfig :
2010-07-31 23:35:26 +02:00
case oldaskconfig :
case oldconfig :
2010-07-31 23:35:28 +02:00
case listnewconfig :
2019-11-04 17:10:08 -05:00
case helpnewconfig :
2012-09-01 01:05:17 +08:00
case olddefconfig :
2019-12-17 18:42:06 +09:00
case yes2modconfig :
case mod2yesconfig :
2021-10-17 19:43:13 +02:00
case mod2noconfig :
2005-04-16 15:20:36 -07:00
conf_read ( NULL ) ;
break ;
2010-07-31 23:35:26 +02:00
case allnoconfig :
case allyesconfig :
case allmodconfig :
2010-07-31 23:35:31 +02:00
case alldefconfig :
2010-07-31 23:35:26 +02:00
case randconfig :
2005-11-08 21:34:49 -08:00
name = getenv ( " KCONFIG_ALLCONFIG " ) ;
2012-05-07 05:37:45 -07:00
if ( ! name )
break ;
if ( ( strcmp ( name , " " ) ! = 0 ) & & ( strcmp ( name , " 1 " ) ! = 0 ) ) {
2012-04-26 01:51:32 -07:00
if ( conf_read_simple ( name , S_DEF_USER ) ) {
fprintf ( stderr ,
2018-05-22 21:36:12 +02:00
" *** Can't read seed configuration \" %s \" ! \n " ,
2012-04-26 01:51:32 -07:00
name ) ;
exit ( 1 ) ;
}
2005-11-08 21:34:49 -08:00
break ;
}
switch ( input_mode ) {
2010-07-31 23:35:26 +02:00
case allnoconfig : name = " allno.config " ; break ;
case allyesconfig : name = " allyes.config " ; break ;
case allmodconfig : name = " allmod.config " ; break ;
2010-07-31 23:35:31 +02:00
case alldefconfig : name = " alldef.config " ; break ;
2010-07-31 23:35:26 +02:00
case randconfig : name = " allrandom.config " ; break ;
2005-11-08 21:34:49 -08:00
default : break ;
}
2012-04-26 01:51:32 -07:00
if ( conf_read_simple ( name , S_DEF_USER ) & &
conf_read_simple ( " all.config " , S_DEF_USER ) ) {
fprintf ( stderr ,
2018-05-22 21:36:12 +02:00
" *** KCONFIG_ALLCONFIG set, but no \" %s \" or \" all.config \" file found \n " ,
2012-04-26 01:51:32 -07:00
name ) ;
exit ( 1 ) ;
}
2005-11-08 21:34:49 -08:00
break ;
2005-04-16 15:20:36 -07:00
default :
break ;
}
2008-09-29 05:27:10 +02:00
2023-11-22 12:47:45 +09:00
if ( conf_errors ( ) )
exit ( 1 ) ;
2008-09-29 05:27:10 +02:00
if ( sync_kconfig ) {
kconfig: make syncconfig update .config regardless of sym_change_count
syncconfig updates the .config only when sym_change_count > 0, i.e.
any change in config symbols has been detected.
Not only symbols but also comments are contained in the .config file.
If only comments are updated, they are not fed back to the .config,
then the stale comments are left-over. Of course, this is just a
matter of comments, but why not fix it.
I see some scenarios where this happens.
Scenario A:
1. You have a source tree that has already been configured.
2. Linus increments the version number in the top-level Makefile
(i.e. he commits a new release)
3. You pull it, and run 'make'
4. syncconfig is invoked because the environment variable,
KERNELVERSION is updated, but the .config is not updated since
no config symbol is changed.
5. The .config file contains a kernel version in the top line:
# Automatically generated file; DO NOT EDIT.
# Linux/arm64 4.18.0-rc2 Kernel Configuration
... which points to a previous version.
Scenario B:
1. You have a source tree that has already been configured.
2. You upgrade the compiler, but it still has the same version number.
This may happen if you regularly build the latest compiler from
the source code.
3. You run 'make'
4. syncconfig is invoked because the environment variable,
CC_VERSION_TEXT is updated, but the .config is not updated since
no config symbol is changed.
5. The .config file contains the version string of the compiler:
#
# Compiler: aarch64-linux-gcc (GCC) 9.0.0 20180628 (experimental)
#
... which carries the information of the old compiler.
If KCONFIG_NOSILENTUPDATE is set, syncconfig is not allowed to update
the .config file. Otherwise, it is fine to update it regardless of
sym_change_count.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-20 16:46:30 +09:00
name = getenv ( " KCONFIG_NOSILENTUPDATE " ) ;
if ( name & & * name ) {
if ( conf_get_changed ( ) ) {
2008-09-29 05:27:10 +02:00
fprintf ( stderr ,
2018-05-22 21:36:12 +02:00
" \n *** The configuration requires explicit update. \n \n " ) ;
2008-09-29 05:27:10 +02:00
return 1 ;
}
kconfig: make syncconfig update .config regardless of sym_change_count
syncconfig updates the .config only when sym_change_count > 0, i.e.
any change in config symbols has been detected.
Not only symbols but also comments are contained in the .config file.
If only comments are updated, they are not fed back to the .config,
then the stale comments are left-over. Of course, this is just a
matter of comments, but why not fix it.
I see some scenarios where this happens.
Scenario A:
1. You have a source tree that has already been configured.
2. Linus increments the version number in the top-level Makefile
(i.e. he commits a new release)
3. You pull it, and run 'make'
4. syncconfig is invoked because the environment variable,
KERNELVERSION is updated, but the .config is not updated since
no config symbol is changed.
5. The .config file contains a kernel version in the top line:
# Automatically generated file; DO NOT EDIT.
# Linux/arm64 4.18.0-rc2 Kernel Configuration
... which points to a previous version.
Scenario B:
1. You have a source tree that has already been configured.
2. You upgrade the compiler, but it still has the same version number.
This may happen if you regularly build the latest compiler from
the source code.
3. You run 'make'
4. syncconfig is invoked because the environment variable,
CC_VERSION_TEXT is updated, but the .config is not updated since
no config symbol is changed.
5. The .config file contains the version string of the compiler:
#
# Compiler: aarch64-linux-gcc (GCC) 9.0.0 20180628 (experimental)
#
... which carries the information of the old compiler.
If KCONFIG_NOSILENTUPDATE is set, syncconfig is not allowed to update
the .config file. Otherwise, it is fine to update it regardless of
sym_change_count.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-20 16:46:30 +09:00
no_conf_write = 1 ;
2008-09-29 05:27:10 +02:00
}
}
2008-06-30 22:45:38 +02:00
switch ( input_mode ) {
2010-07-31 23:35:26 +02:00
case allnoconfig :
2008-06-30 22:45:38 +02:00
conf_set_all_new_symbols ( def_no ) ;
break ;
2010-07-31 23:35:26 +02:00
case allyesconfig :
2008-06-30 22:45:38 +02:00
conf_set_all_new_symbols ( def_yes ) ;
break ;
2010-07-31 23:35:26 +02:00
case allmodconfig :
2008-06-30 22:45:38 +02:00
conf_set_all_new_symbols ( def_mod ) ;
break ;
2010-07-31 23:35:31 +02:00
case alldefconfig :
conf_set_all_new_symbols ( def_default ) ;
break ;
2010-07-31 23:35:26 +02:00
case randconfig :
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 19:35:21 +09:00
conf_set_all_new_symbols ( def_random ) ;
2008-06-30 22:45:38 +02:00
break ;
2010-07-31 23:35:26 +02:00
case defconfig :
2008-06-30 23:02:59 +02:00
conf_set_all_new_symbols ( def_default ) ;
break ;
2010-07-31 23:35:34 +02:00
case savedefconfig :
break ;
2019-12-17 18:42:06 +09:00
case yes2modconfig :
2021-10-17 19:43:13 +02:00
conf_rewrite_tristates ( yes , mod ) ;
2019-12-17 18:42:06 +09:00
break ;
case mod2yesconfig :
2021-10-17 19:43:13 +02:00
conf_rewrite_tristates ( mod , yes ) ;
break ;
case mod2noconfig :
conf_rewrite_tristates ( mod , no ) ;
2019-12-17 18:42:06 +09:00
break ;
2010-07-31 23:35:26 +02:00
case oldaskconfig :
2008-09-29 05:27:10 +02:00
rootEntry = & rootmenu ;
conf ( & rootmenu ) ;
kconfig: hide irrelevant sub-menus for oldconfig
Historically, "make oldconfig" has changed its behavior several times,
quieter or louder. (I attached the history below.) Currently, it is
not as quiet as it should be. This commit addresses it.
Test Case
---------
---------------------------(Kconfig)----------------------------
menu "menu"
config FOO
bool "foo"
menu "sub menu"
config BAR
bool "bar"
endmenu
endmenu
menu "sibling menu"
config BAZ
bool "baz"
endmenu
----------------------------------------------------------------
---------------------------(.config)----------------------------
CONFIG_BAR=y
CONFIG_BAZ=y
----------------------------------------------------------------
With the Kconfig and .config above, "make silentoldconfig" and
"make oldconfig" work differently, like follows:
$ make silentoldconfig
scripts/kconfig/conf --silentoldconfig Kconfig
*
* Restart config...
*
*
* menu
*
foo (FOO) [N/y/?] (NEW) y
#
# configuration written to .config
#
$ make oldconfig
scripts/kconfig/conf --oldconfig Kconfig
*
* Restart config...
*
*
* menu
*
foo (FOO) [N/y/?] (NEW) y
*
* sub menu
*
bar (BAR) [Y/n/?] y
#
# configuration written to .config
#
Both hide "sibling node" since it is irrelevant. The difference is
that silentoldconfig hides "sub menu" whereas oldconfig does not.
The behavior of silentoldconfig is preferred since the "sub menu"
does not contain any new symbol.
The root cause is in conf(). There are three input modes that can
call conf(); oldaskconfig, oldconfig, and silentoldconfig.
Everytime conf() encounters a menu entry, it calls check_conf() to
check if it contains new symbols. If no new symbol is found, the
menu is just skipped.
Currently, this happens only when input_mode == silentoldconfig.
The oldaskconfig enters into the check_conf() loop as silentoldconfig,
so oldaskconfig works likewise for the second loop or later, but it
never happens for oldconfig. So, irrelevant sub-menus are shown for
oldconfig.
Change the test condition to "input_mode != oldaskconfig". This is
false only for the first loop of oldaskconfig; it must ask the user
all symbols, so no need to call check_conf().
History of oldconfig
--------------------
[0] Originally, "make oldconfig" was as loud as "make config" (It
showed the entire .config file)
[1] Commit cd9140e1e73a ("kconfig: make oldconfig is now less chatty")
made oldconfig quieter, but it was still less quieter than
silentoldconfig. (oldconfig did not hide sub-menus)
[2] Commit 204c96f60904 ("kconfig: fix silentoldconfig") changed
the input_mode of oldconfig to "ask_silent" from "ask_new".
So, oldconfig really became as quiet as silentoldconfig.
(oldconfig hided irrelevant sub-menus)
[3] Commit 4062f1a4c030 ("kconfig: use long options in conf") made
oldconfig as loud as [0] due to misconversion.
[4] Commit 14828349719a ("kconfig: fix make oldconfig") addressed
the misconversion of [3], but it made oldconfig quieter only to
the same level as [1], not [2].
This commit is restoring the behavior of [2].
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-02-28 09:15:24 +09:00
input_mode = oldconfig ;
2008-09-29 05:27:10 +02:00
/* fall through */
2010-08-06 07:13:54 +02:00
case oldconfig :
2010-07-31 23:35:28 +02:00
case listnewconfig :
2019-11-04 17:10:08 -05:00
case helpnewconfig :
2018-03-01 15:34:37 +09:00
case syncconfig :
2008-09-29 05:27:10 +02:00
/* Update until a loop caused no more changes */
do {
conf_cnt = 0 ;
check_conf ( & rootmenu ) ;
2018-02-28 09:15:23 +09:00
} while ( conf_cnt ) ;
2018-02-28 09:15:21 +09:00
break ;
case olddefconfig :
default :
2008-06-30 22:45:38 +02:00
break ;
}
2005-04-16 15:20:36 -07:00
2023-11-22 12:47:45 +09:00
if ( sym_dep_errors ( ) )
exit ( 1 ) ;
kconfig: allow all config targets to write auto.conf if missing
Currently, only syncconfig creates or updates include/config/auto.conf
and some other files. Other config targets create or update only the
.config file.
When you configure and build the kernel from a pristine source tree,
any config target is followed by syncconfig in the build stage since
include/config/auto.conf is missing.
We are moving compiler tests from Makefile to Kconfig. It means that
parsing Kconfig files will be more costly since Kconfig invokes the
compiler commands internally. Thus, we want to avoid invoking Kconfig
twice (one for *config to create the .config, and one for syncconfig
to synchronize the auto.conf). If auto.conf does not exist, we can
generate all configuration files in the first configuration stage,
which will save the syncconfig in the build stage.
Please note this should be done only when auto.conf is missing. If
*config blindly did this, time stamp files under include/config/ would
be unnecessarily touched, triggering unneeded rebuild of objects.
I assume a scenario like this:
1. You have a source tree that has already been built
with CONFIG_FOO disabled
2. Run "make menuconfig" to enable CONFIG_FOO
3. CONFIG_FOO turns out to be unnecessary.
Run "make menuconfig" again to disable CONFIG_FOO
4. Run "make"
In this case, include/config/foo.h should not be touched since there
is no change in CONFIG_FOO. The sync process should be delayed until
the user really attempts to build the kernel.
This commit has another motivation; I want to suppress the 'No such
file or directory' warning from the 'include' directive.
The top-level Makefile includes auto.conf with '-include' directive,
like this:
ifeq ($(dot-config),1)
-include include/config/auto.conf
endif
This looks strange because auto.conf is mandatory when dot-config is 1.
I guess only the reason of using '-include' is to suppress the warning
'include/config/auto.conf: No such file or directory' when building
from a clean tree. However, this has a side-effect; Make considers
the files included by '-include' are optional. Hence, Make continues
to build even if it fails to generate include/config/auto.conf. I will
change this in the next commit, but the warning message is annoying.
(At least, kbuild test robot reports it as a regression.)
With this commit, Kconfig will generate all configuration files together
with the .config and I guess it is a solution good enough to suppress
the warning.
Note:
GNU Make 4.2 or later does not display the warning from the 'include'
directive if include files are successfully generated. See GNU Make
commit 87a5f98d248f ("[SV 102] Don't show unnecessary include file
errors.") However, older GNU Make versions are still widely used.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-20 16:46:31 +09:00
if ( input_mode = = savedefconfig ) {
2010-07-31 23:35:34 +02:00
if ( conf_write_defconfig ( defconfig_file ) ) {
2018-05-22 21:36:12 +02:00
fprintf ( stderr , " n*** Error while saving defconfig to: %s \n \n " ,
2014-06-10 19:08:13 +09:00
defconfig_file ) ;
2010-07-31 23:35:34 +02:00
return 1 ;
}
2019-11-04 17:10:08 -05:00
} else if ( input_mode ! = listnewconfig & & input_mode ! = helpnewconfig ) {
kconfig: allow all config targets to write auto.conf if missing
Currently, only syncconfig creates or updates include/config/auto.conf
and some other files. Other config targets create or update only the
.config file.
When you configure and build the kernel from a pristine source tree,
any config target is followed by syncconfig in the build stage since
include/config/auto.conf is missing.
We are moving compiler tests from Makefile to Kconfig. It means that
parsing Kconfig files will be more costly since Kconfig invokes the
compiler commands internally. Thus, we want to avoid invoking Kconfig
twice (one for *config to create the .config, and one for syncconfig
to synchronize the auto.conf). If auto.conf does not exist, we can
generate all configuration files in the first configuration stage,
which will save the syncconfig in the build stage.
Please note this should be done only when auto.conf is missing. If
*config blindly did this, time stamp files under include/config/ would
be unnecessarily touched, triggering unneeded rebuild of objects.
I assume a scenario like this:
1. You have a source tree that has already been built
with CONFIG_FOO disabled
2. Run "make menuconfig" to enable CONFIG_FOO
3. CONFIG_FOO turns out to be unnecessary.
Run "make menuconfig" again to disable CONFIG_FOO
4. Run "make"
In this case, include/config/foo.h should not be touched since there
is no change in CONFIG_FOO. The sync process should be delayed until
the user really attempts to build the kernel.
This commit has another motivation; I want to suppress the 'No such
file or directory' warning from the 'include' directive.
The top-level Makefile includes auto.conf with '-include' directive,
like this:
ifeq ($(dot-config),1)
-include include/config/auto.conf
endif
This looks strange because auto.conf is mandatory when dot-config is 1.
I guess only the reason of using '-include' is to suppress the warning
'include/config/auto.conf: No such file or directory' when building
from a clean tree. However, this has a side-effect; Make considers
the files included by '-include' are optional. Hence, Make continues
to build even if it fails to generate include/config/auto.conf. I will
change this in the next commit, but the warning message is annoying.
(At least, kbuild test robot reports it as a regression.)
With this commit, Kconfig will generate all configuration files together
with the .config and I guess it is a solution good enough to suppress
the warning.
Note:
GNU Make 4.2 or later does not display the warning from the 'include'
directive if include files are successfully generated. See GNU Make
commit 87a5f98d248f ("[SV 102] Don't show unnecessary include file
errors.") However, older GNU Make versions are still widely used.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-20 16:46:31 +09:00
if ( ! no_conf_write & & conf_write ( NULL ) ) {
2018-05-22 21:36:12 +02:00
fprintf ( stderr , " \n *** Error during writing of the configuration. \n \n " ) ;
2008-09-29 05:27:10 +02:00
exit ( 1 ) ;
}
kconfig: allow all config targets to write auto.conf if missing
Currently, only syncconfig creates or updates include/config/auto.conf
and some other files. Other config targets create or update only the
.config file.
When you configure and build the kernel from a pristine source tree,
any config target is followed by syncconfig in the build stage since
include/config/auto.conf is missing.
We are moving compiler tests from Makefile to Kconfig. It means that
parsing Kconfig files will be more costly since Kconfig invokes the
compiler commands internally. Thus, we want to avoid invoking Kconfig
twice (one for *config to create the .config, and one for syncconfig
to synchronize the auto.conf). If auto.conf does not exist, we can
generate all configuration files in the first configuration stage,
which will save the syncconfig in the build stage.
Please note this should be done only when auto.conf is missing. If
*config blindly did this, time stamp files under include/config/ would
be unnecessarily touched, triggering unneeded rebuild of objects.
I assume a scenario like this:
1. You have a source tree that has already been built
with CONFIG_FOO disabled
2. Run "make menuconfig" to enable CONFIG_FOO
3. CONFIG_FOO turns out to be unnecessary.
Run "make menuconfig" again to disable CONFIG_FOO
4. Run "make"
In this case, include/config/foo.h should not be touched since there
is no change in CONFIG_FOO. The sync process should be delayed until
the user really attempts to build the kernel.
This commit has another motivation; I want to suppress the 'No such
file or directory' warning from the 'include' directive.
The top-level Makefile includes auto.conf with '-include' directive,
like this:
ifeq ($(dot-config),1)
-include include/config/auto.conf
endif
This looks strange because auto.conf is mandatory when dot-config is 1.
I guess only the reason of using '-include' is to suppress the warning
'include/config/auto.conf: No such file or directory' when building
from a clean tree. However, this has a side-effect; Make considers
the files included by '-include' are optional. Hence, Make continues
to build even if it fails to generate include/config/auto.conf. I will
change this in the next commit, but the warning message is annoying.
(At least, kbuild test robot reports it as a regression.)
With this commit, Kconfig will generate all configuration files together
with the .config and I guess it is a solution good enough to suppress
the warning.
Note:
GNU Make 4.2 or later does not display the warning from the 'include'
directive if include files are successfully generated. See GNU Make
commit 87a5f98d248f ("[SV 102] Don't show unnecessary include file
errors.") However, older GNU Make versions are still widely used.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-20 16:46:31 +09:00
/*
* Create auto . conf if it does not exist .
* This prevents GNU Make 4.1 or older from emitting
* " include/config/auto.conf: No such file or directory "
* in the top - level Makefile
*
* syncconfig always creates or updates auto . conf because it is
* used during the build .
*/
if ( conf_write_autoconf ( sync_kconfig ) & & sync_kconfig ) {
fprintf ( stderr ,
" \n *** Error during sync of the configuration. \n \n " ) ;
return 1 ;
}
2006-06-08 22:12:39 -07:00
}
2010-07-31 23:35:28 +02:00
return 0 ;
2005-04-16 15:20:36 -07:00
}