We at Red Hat/Fedora have generally tried to have a per file breakdown of
every config option we set. This makes it easy for us to add new options
when they are exposed and keep a changelog of why they were set.
A Fedora example is here:
https://src.fedoraproject.org/cgit/rpms/kernel.git/tree/configs/fedora/generic
Using various merge scripts, we build up a config file and run it through
'make listnewconfig' and 'make oldnoconfig'. The idea is to print out new
config options that haven't been manually set and use the default until
a patch is posted to set it properly.
To speed things up, it would be nice to make it easier to generate a
patch to post the default setting. The output of 'make listnewconfig'
has two issues that limit us:
- it doesn't provide the default value
- it doesn't provide the new 'choice' options that get flagged in
'oldconfig'
This patch extends 'listnewconfig' to address the above two issues.
This allows us to run a script
make listnewconfig | rhconfig-tool -o patches; git send-email patches/
The output of 'make listnewconfig':
CONFIG_NET_EMATCH_IPT
CONFIG_IPVLAN
CONFIG_ICE
CONFIG_NET_VENDOR_NI
CONFIG_IEEE802154_MCR20A
CONFIG_IR_IMON_DECODER
CONFIG_IR_IMON_RAW
The new output of 'make listnewconfig':
CONFIG_KERNEL_XZ=n
CONFIG_KERNEL_LZO=n
CONFIG_NET_EMATCH_IPT=n
CONFIG_IPVLAN=n
CONFIG_ICE=n
CONFIG_NET_VENDOR_NI=y
CONFIG_IEEE802154_MCR20A=n
CONFIG_IR_IMON_DECODER=n
CONFIG_IR_IMON_RAW=n
Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Files generated by if_changed* must be added to 'targets' to include
*.cmd files. Otherwise, they would be regenerated every time.
The build system automatically adds objects to 'targets' where
appropriate, such as obj-y, extra-y, etc. but does nothing for
intermediate files. So, each Makefile needs to add them by itself.
There are some common cases where objects are generated by chained
rules. Lexers and parsers are compiled like follows:
%.lex.o <- %.lex.c <- %.l
%.tab.o <- %.tab.c <- %.y
They are common patterns, so it is reasonable to take care of them
in the core Makefile instead of requiring each Makefile to do so.
At this moment, you cannot delete 'target += zconf.lex.c' in the
Kconfig Makefile because zconf.lex.c is included from zconf.tab.c
instead of being compiled separately. It should be deleted after
Kconfig is more refactored.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Frank Rowand <frowand.list@gmail.com>
Files suffixed by .lex.c, .tab.[ch] are generated lexers, parsers,
respectively. Clean them up globally from the top Makefile.
Some of the final host programs those lexer/parser are linked into
are necessary for building external modules, but the intermediates
are unneeded. They can be cleaned away by 'make clean' instead of
'make mrproper'.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Frank Rowand <frowand.list@gmail.com>
These patterns are common to host programs that require lexer and parser.
Move them to the top .gitignore.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Frank Rowand <frowand.list@gmail.com>
Pull Kconfig updates from Masahiro Yamada:
- improve checkpatch for more precise Kconfig code checking
- clarify effective selects by grouping reverse dependencies in help
- do not write out '# CONFIG_FOO is not set' from invisible symbols
- make oldconfig as silent as it should be
- rename 'silentoldconfig' to 'syncconfig'
- add unit-test framework and several test cases
- warn unmet dependency of tristate symbols
- make unmet dependency warnings readable, removing false positives
- improve recursive include detection
- use yylineno to simplify the line number tracking
- misc cleanups
* tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (30 commits)
kconfig: use yylineno option instead of manual lineno increments
kconfig: detect recursive inclusion earlier
kconfig: remove duplicated file name and lineno of recursive inclusion
kconfig: do not include both curses.h and ncurses.h for nconfig
kconfig: make unmet dependency warnings readable
kconfig: warn unmet direct dependency of tristate symbols selected by y
kconfig: tests: test if recursive inclusion is detected
kconfig: tests: test if recursive dependencies are detected
kconfig: tests: test randconfig for choice in choice
kconfig: tests: test defconfig when two choices interact
kconfig: tests: check visibility of tristate choice values in y choice
kconfig: tests: check unneeded "is not set" with unmet dependency
kconfig: tests: test if new symbols in choice are asked
kconfig: tests: test automatic submenu creation
kconfig: tests: add basic choice tests
kconfig: tests: add framework for Kconfig unit testing
kbuild: add PYTHON2 and PYTHON3 variables
kconfig: remove redundant streamline_config.pl prerequisite
kconfig: rename silentoldconfig to syncconfig
kconfig: invoke oldconfig instead of silentoldconfig from local*config
...
Tracking the line number by hand is error-prone since you need to
increment it in every \n matching pattern.
If '%option yylineno' is set, flex defines 'yylineno' to contain the
current line number and automatically updates it each time it reads a
\n character. This is much more convenient although the lexer does
not initializes yylineno, so you need to set it to 1 each time you
start reading a new file, and restore it you go back to the previous
file.
I tested this with DEBUG_PARSE, and confirmed the same dump message
was produced.
I removed the perf-report option. Otherwise, I see the following
message:
%option yylineno entails a performance penalty ONLY on rules that
can match newline characters
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, the recursive inclusion is not detected when the offending
file is about to be included; it is detected the offending file is
about to include the *next* file. This is because the detection loop
does not involve the file being included.
Do this check against the file that is about to be included so that
the recursive inclusion is detected before unneeded parsing happens.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
As in the unit test, the error message for the recursive inclusion
looks like this:
Kconfig.inc1:4: recursive inclusion detected. Inclusion path:
current file : 'Kconfig.inc1'
included from: 'Kconfig.inc3:1'
included from: 'Kconfig.inc2:3'
included from: 'Kconfig.inc1:4'
The 'Kconfig.inc1:4' is duplicated in the first and last lines.
Also, the single quotes do not help readability.
Change the message like follows:
Recursive inclusion detected.
Inclusion path:
current file : Kconfig.inc1
included from: Kconfig.inc3:1
included from: Kconfig.inc2:3
included from: Kconfig.inc1:4
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
nconf.h includes <curses.h> and "ncurses.h", but it does not need to
include both. Generally, it should fall back to curses.h only when
ncurses.h is not found. But, looks like it has never happened;
these includes have been here for many years since commit 692d97c380
("kconfig: new configuration interface (nconfig)"), and nobody has
complained about hard-coding of ncurses.h . Let's simply drop the
curses.h inclusion.
I replaced "ncurses.h" with <ncurses.h> since it is not a local file.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, the unmet dependency warnings end up with endlessly long
expressions, most of which are false positives.
Here is test code to demonstrate how it currently works.
[Test Case]
config DEP1
def_bool y
config DEP2
bool "DEP2"
config A
bool "A"
select E
config B
bool "B"
depends on DEP2
select E
config C
bool "C"
depends on DEP1 && DEP2
select E
config D
def_bool n
select E
config E
bool
depends on DEP1 && DEP2
[Result]
$ make config
scripts/kconfig/conf --oldaskconfig Kconfig
*
* Linux Kernel Configuration
*
DEP2 (DEP2) [N/y/?] (NEW) n
A (A) [N/y/?] (NEW) y
warning: (A && B && D) selects E which has unmet direct
dependencies (DEP1 && DEP2)
Here, I see some points to be improved.
First, '(A || B || D)' would make more sense than '(A && B && D)'.
I am not sure if this is intentional, but expr_simplify_unmet_dep()
turns OR expressions into AND, like follows:
case E_OR:
return expr_alloc_and(
Second, we see false positives. 'A' is a real unmet dependency.
'B' is false positive because 'DEP1' is fixed to 'y', and 'B' depends
on 'DEP2'. 'C' was correctly dropped by expr_simplify_unmet_dep().
'D' is also false positive because it has no chance to be enabled.
Current expr_simplify_unmet_dep() cannot avoid those false positives.
After all, I decided to use the same helpers as used for printing
reverse dependencies in the help.
With this commit, unreadable warnings (most of the reported symbols are
false positives) in the real world:
$ make ARCH=score allyesconfig
scripts/kconfig/conf --allyesconfig Kconfig
warning: (HWSPINLOCK_QCOM && AHCI_MTK && STMMAC_PLATFORM &&
DWMAC_IPQ806X && DWMAC_LPC18XX && DWMAC_OXNAS && DWMAC_ROCKCHIP &&
DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_GEMINI &&
PINCTRL_OXNAS && PINCTRL_ROCKCHIP && PINCTRL_DOVE &&
PINCTRL_ARMADA_37XX && PINCTRL_STM32 && S3C2410_WATCHDOG &&
VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 &&
LPC18XX_DMAMUX && VIDEO_OMAP4 && COMMON_CLK_GEMINI &&
COMMON_CLK_ASPEED && COMMON_CLK_NXP && COMMON_CLK_OXNAS &&
COMMON_CLK_BOSTON && QCOM_ADSP_PIL && QCOM_Q6V5_PIL && QCOM_GSBI &&
ATMEL_EBI && ST_IRQCHIP && RESET_IMX7 && PHY_HI6220_USB &&
PHY_RALINK_USB && PHY_ROCKCHIP_PCIE && PHY_DA8XX_USB) selects
MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)
warning: (PINCTRL_AT91 && PINCTRL_AT91PIO4 && PINCTRL_OXNAS &&
PINCTRL_PISTACHIO && PINCTRL_PIC32 && PINCTRL_MESON &&
PINCTRL_NOMADIK && PINCTRL_MTK && PINCTRL_MT7622 && GPIO_TB10X)
selects OF_GPIO which has unmet direct dependencies (GPIOLIB && OF &&
HAS_IOMEM)
warning: (FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && LOCKDEP)
selects FRAME_POINTER which has unmet direct dependencies
(DEBUG_KERNEL && (CRIS || M68K || FRV || UML || SUPERH || BLACKFIN ||
MN10300 || METAG) || ARCH_WANT_FRAME_POINTERS)
will be turned into:
$ make ARCH=score allyesconfig
scripts/kconfig/conf --allyesconfig Kconfig
WARNING: unmet direct dependencies detected for MFD_SYSCON
Depends on [n]: HAS_IOMEM [=n]
Selected by [y]:
- PINCTRL_STM32 [=y] && PINCTRL [=y] && (ARCH_STM32 ||
COMPILE_TEST [=y]) && OF [=y]
- RTC_DRV_AT91SAM9 [=y] && RTC_CLASS [=y] && (ARCH_AT91 ||
COMPILE_TEST [=y])
- RESET_IMX7 [=y] && RESET_CONTROLLER [=y]
- PHY_HI6220_USB [=y] && (ARCH_HISI && ARM64 ||
COMPILE_TEST [=y])
- PHY_RALINK_USB [=y] && (RALINK || COMPILE_TEST [=y])
- PHY_ROCKCHIP_PCIE [=y] && (ARCH_ROCKCHIP && OF [=y] ||
COMPILE_TEST [=y])
WARNING: unmet direct dependencies detected for OF_GPIO
Depends on [n]: GPIOLIB [=y] && OF [=y] && HAS_IOMEM [=n]
Selected by [y]:
- PINCTRL_MTK [=y] && PINCTRL [=y] && (ARCH_MEDIATEK ||
COMPILE_TEST [=y]) && OF [=y]
- PINCTRL_MT7622 [=y] && PINCTRL [=y] && (ARCH_MEDIATEK ||
COMPILE_TEST [=y]) && OF [=y] && (ARM64 || COMPILE_TEST [=y])
WARNING: unmet direct dependencies detected for FRAME_POINTER
Depends on [n]: DEBUG_KERNEL [=y] && (CRIS || M68K || FRV || UML ||
SUPERH || BLACKFIN || MN10300 || METAG) || ARCH_WANT_FRAME_POINTERS [=n]
Selected by [y]:
- LATENCYTOP [=y] && DEBUG_KERNEL [=y] && STACKTRACE_SUPPORT [=y] &&
PROC_FS [=y] && !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND &&
!ARC && !X86
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Petr Vorel <petr.vorel@gmail.com>
Commit 246cf9c26b ("kbuild: Warn on selecting symbols with unmet
direct dependencies") forcibly promoted ->dir_dep.tri to yes from mod.
So, the unmet direct dependencies of tristate symbols are not reported.
[Test Case]
config MODULES
def_bool y
option modules
config A
def_bool y
select B
config B
tristate "B"
depends on m
This causes unmet dependency because 'B' is forced 'y' ignoring
'depends on m'. This should be warned.
On the other hand, the following case ('B' is bool) should not be
warned, so 'depends on m' for bool symbols should be naturally treated
as 'depends on y'.
[Test Case2 (not unmet dependency)]
config MODULES
def_bool y
option modules
config A
def_bool y
select B
config B
bool "B"
depends on m
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
If recursive inclusion is detected, it should fail with error
messages. Test this.
This also tests the line numbers in the error message, fixed by
commit 5ae6fcc4bb ("kconfig: fix line number in recursive inclusion
error message").
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Recursive dependency should be detected and warned. Test this.
This indirectly tests the line number increments.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Commit 3b9a19e089 ("kconfig: loop as long as we changed some symbols
in randconfig") fixed randconfig where a choice contains a sub-choice.
Prior to that commit, the sub-choice values were not set.
I am not sure whether this is an intended feature or just something
people discovered works, but it is used in the real world;
drivers/usb/gadget/legacy/Kconfig is source'd in a choice context,
then creates a sub-choice in it.
For the test case in this commit, there are 3 possible results.
Case 1:
CONFIG_A=y
# CONFIG_B is not set
Case 2:
# CONFIG_A is not set
CONFIG_B=y
CONFIG_C=y
# CONFIG_D is not set
Case 3:
# CONFIG_A is not set
CONFIG_B=y
# CONFIG_C is not set
CONFIG_D=y
CONFIG_E=y
So, this test iterates several times, and checks if the result is
either of the three.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Commit fbe98bb9ed ("kconfig: Fix defconfig when one choice menu
selects options that another choice menu depends on") fixed defconfig
when two choices interact (i.e. calculating the visibility of a choice
requires to calculate another choice).
The test code in that commit log was based on the real world example,
and complicated. So, I shrunk it down to the following:
defconfig.choice:
---8<---
CONFIG_CHOICE_VAL0=y
---8<---
---8<---
config MODULES
def_bool y
option modules
choice
prompt "Choice"
config CHOICE_VAL0
tristate "Choice 0"
config CHOICE_VAL1
tristate "Choice 1"
endchoice
choice
prompt "Another choice"
depends on CHOICE_VAL0
config DUMMY
bool "dummy"
endchoice
---8<---
Prior to commit fbe98bb9ed,
$ scripts/kconfig/conf --defconfig=defconfig.choice Kconfig.choice
resulted in:
CONFIG_MODULES=y
CONFIG_CHOICE_VAL0=m
# CONFIG_CHOICE_VAL1 is not set
CONFIG_DUMMY=y
where the expected result would be:
CONFIG_MODULES=y
CONFIG_CHOICE_VAL0=y
# CONFIG_CHOICE_VAL1 is not set
CONFIG_DUMMY=y
Roughly, this weird behavior happened like this:
Symbols are calculated a couple of times. First, all symbols are
calculated in conf_read(). The first 'choice' is evaluated to 'y'
due to the SYMBOL_DEF_USER flag, but sym_calc_choice() clears it
unless all of its choice values are explicitly set by the user.
conf_set_all_new_symbols() clears all SYMBOL_VALID flags. Then, only
choices are calculated. Here, the SYMBOL_DEF_USER for the first choice
has been forgotten, so it is evaluated to 'm'. set_all_choice_values()
sets SYMBOL_DEF_USER again to choice symbols.
When calculating the second choice, due to 'depends on CHOICE_VAL0',
it triggers the calculation of CHOICE_VAL0. As a result, SYMBOL_VALID
is set for CHOICE_VAL0.
Symbols except choices get the final chance of re-calculation in
conf_write(). In a normal case, CHOICE_VAL0 would be re-calculated,
then the first choice would be indirectly re-calculated with the
SYMBOL_DEF_USER which has been recalled by set_all_choice_values(),
which would be evaluated to 'y'. But, in this case, CHOICE_VAL0 has
already been marked as SYMBOL_VALID, so this re-calculation does not
happen. Then, =m from the conf_set_all_new_symbols() phase is written
out to the .config file.
Add a unit test for this naive case.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
If tristate choice values depend on symbols set to 'm', they should be
hidden when the choice containing them is changed from 'm' to 'y'
(i.e. exclusive choice).
This issue was fixed by commit fa64e5f6a3 ("kconfig/symbol.c: handle
choice_values that depend on 'm' symbols").
Add a test case to avoid regression.
For the input in this unit test, there is a room for argument if
"# CONFIG_CHOICE1 is not set" should be written to the .config file.
After commit fa64e5f6a3, this line was written to the .config file.
With commit cb67ab2cd2 ("kconfig: do not write choice values when
their dependency becomes n"), it is not written now.
In this test, "# CONFIG_CHOICE1 is not set" is don't care.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Commit cb67ab2cd2 ("kconfig: do not write choice values when their
dependency becomes n") fixed a problem where "# CONFIG_... is not set"
for choice values are wrongly written into the .config file when they
are once visible, then become invisible later.
Add a test for this naive case.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
If new choice values are added with new dependency, and they become
visible during user configuration, oldconfig should recognize them
as (NEW), and ask the user for choice.
This issue was fixed by commit 5d09598d48 ("kconfig: fix new choices
being skipped upon config update").
This is a subtle corner case. Add a test case to avoid breakage.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
If a symbols has dependency on the preceding symbol, the menu entry
should become the submenu of the preceding one, and displayed with
deeper indentation.
This is done by restructuring the menu tree in menu_finalize().
It is a bit complicated computation, so let's add a test case.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
The calculation of 'choice' is a bit complicated part in Kconfig.
The behavior of 'y' choice is intuitive. If choice values are tristate,
the choice can be 'm' where each value can be enabled independently.
Also, if a choice is marked as 'optional', the whole choice can be
invisible.
Test basic functionality of choice.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Many parts in Kconfig are so cryptic and need refactoring. However,
its complexity prevents us from moving forward. There are several
naive corner cases where it is difficult to notice breakage. If
those are covered by unit tests, we will be able to touch the code
with more confidence.
Here is a simple test framework based on pytest. The conftest.py
provides a fixture useful to run commands such as 'oldaskconfig' etc.
and to compare the resulted .config, stdout, stderr with expectations.
How to add test cases?
----------------------
For each test case, you should create a subdirectory under
scripts/kconfig/tests/ (so test cases are separated from each other).
Every test case directory should contain the following files:
- __init__.py: describes test functions
- Kconfig: the top level Kconfig file for the test
To do a useful job, test cases generally need additional data like
input .config and information about expected results.
How to run tests?
-----------------
You need python3 and pytest. Then, run "make testconfig". O= option
is supported. If V=1 is given, detailed logs captured during tests
are displayed.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
The local{yes,mod}config targets currently have streamline_config.pl as
a prerequisite. This is redundant, because streamline_config.pl is a
checked-in file with no prerequisites.
Remove the prerequisite and reference streamline_config.pl directly in
the recipe of the rule instead.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
As commit cedd55d49d ("kconfig: Remove silentoldconfig from help
and docs; fix kconfig/conf's help") mentioned, 'silentoldconfig' is a
historical misnomer. That commit removed it from help and docs since
it is an internal interface. If so, it should be allowed to rename
it to something more intuitive. 'syncconfig' is the one I came up
with because it updates the .config if necessary, then synchronize
include/generated/autoconf.h and include/config/* with it.
You should not manually invoke 'silentoldcofig'. Display warning if
used in case existing scripts are doing wrong.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
The purpose of local{yes,mod}config is to arrange the .config file
based on actually loaded modules. It is unnecessary to update
include/generated/autoconf.h and include/config/* stuff here.
They will be updated as needed during the build.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
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 cd9140e1e7 ("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 204c96f609 ("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 4062f1a4c0 ("kconfig: use long options in conf") made
oldconfig as loud as [0] due to misconversion.
[4] Commit 1482834971 ("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>
