When we generate the help text of a symbol (e.g. when a user presses '?'
in menuconfig), we do two things:
1. We iterate through every prompt that belongs to that symbol,
printing its text and its location in the menu tree.
2. We print symbol-wide information that's not linked to a particular
prompt, such as what it selects/is selected by and what it
implies/is implied by.
Each prompt we print for 1 starts with a line that's not indented
indicating where the prompt is defined, then continues with indented
lines that describe properties of that particular definition.
Once we get to 2, however, we print all the global data indented as
well! Visually, this makes it look like the symbol-wide data is
associated with the last prompt we happened to print rather than
the symbol as a whole.
Fix this by removing the indentation for symbol-wide information.
Before:
Symbol: CPU_FREQ [=n]
Type : bool
Defined at drivers/cpufreq/Kconfig:4
Prompt: CPU Frequency scaling
Location:
-> CPU Power Management
-> CPU Frequency scaling
Selects: SRCU [=n]
Selected by [n]:
- ARCH_SA1100 [=n] && <choice>
After:
Symbol: CPU_FREQ [=n]
Type : bool
Defined at drivers/cpufreq/Kconfig:4
Prompt: CPU Frequency scaling
Location:
-> CPU Power Management
-> CPU Frequency scaling
Selects: SRCU [=n]
Selected by [n]:
- ARCH_SA1100 [=n] && <choice>
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Kconfig makes a distinction between dependencies (defined by "depends
on" expressions and enclosing "if" blocks) and visibility (which
includes all dependencies, but also includes inline "if" expressions of
individual properties as well as, for prompts, "visible if" expressions
of enclosing menus).
Before commit bcdedcc1af ("menuconfig: print more info for symbol
without prompts"), the "Depends on" lines of a symbol's help text
indicated the visibility of the prompt property they appeared under.
After bcdedcc1af, there was always only a single "Depends on" line,
which indicated the visibility of the first P_SYMBOL property of the
symbol. Since P_SYMBOLs never have inline if expressions, this was in
effect the same as the dependencies of the menu item that the P_SYMBOL
was attached to.
Neither of these situations accurately conveyed the dependencies of a
symbol--the first because it was actually the visibility, and the second
because it only showed the dependencies from a single definition.
With this series, we are back to printing separate dependencies for each
definition, but we print the actual dependencies (rather than the
visibility) in the "Depends on" line. However, it can still be useful to
know the visibility of a prompt, so this patch adds a "Visible if" line
that shows the visibility only if the visibility is different from the
dependencies (which it isn't for most prompts in Linux).
Before:
Symbol: THUMB2_KERNEL [=n]
Type : bool
Defined at arch/arm/Kconfig:1417
Prompt: Compile the kernel in Thumb-2 mode
Depends on: (CPU_V7 [=y] || CPU_V7M [=n]) && !CPU_V6 [=n] && !CPU_V6K [=n]
Location:
-> Kernel Features
Selects: ARM_UNWIND [=n]
After:
Symbol: THUMB2_KERNEL [=n]
Type : bool
Defined at arch/arm/Kconfig:1417
Prompt: Compile the kernel in Thumb-2 mode
Depends on: (CPU_V7 [=y] || CPU_V7M [=n]) && !CPU_V6 [=n] && !CPU_V6K [=n]
Visible if: (CPU_V7 [=y] || CPU_V7M [=n]) && !CPU_V6 [=n] && !CPU_V6K [=n] && !CPU_THUMBONLY [=n]
Location:
-> Kernel Features
Selects: ARM_UNWIND [=n]
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
In Kconfig, each symbol (representing a config option) can be defined in
multiple places. Each definition may or may not have a prompt, which
allows the option to be set via an interface like menuconfig. Each
definition has a set of dependencies, which determine whether its prompt
is visible and whether other pieces of the definition, like a default
value, take effect.
Historically, a symbol's help text (i.e. what's shown when a user
presses '?' in menuconfig) contained some symbol-wide information not
tied to any particular definition (e.g. what other symbols it selects)
as well as the location (file name and line number) and dependencies of
each prompt. Notably, the help text did not show the location or
dependencies of definitions without prompts.
Because this made it hard to reason about symbols that had no prompts,
commit bcdedcc1af ("menuconfig: print more info for symbol without
prompts") changed the help text so that, instead of containing the
location and dependencies of each prompt, it contained the location and
dependencies of the symbol's first definition, regardless of whether or
not that definition had a prompt.
For symbols with only one definition, that change makes sense. However,
it breaks down for symbols with multiple definitions: each definition
has its own set of dependencies (the `dep` field of `struct menu`), and
those dependencies are ORed together to get the symbol's dependency list
(the `dir_dep` field of `struct symbol`). By printing only the
dependencies of the first definition, the help text misleads users into
believing that an option is more narrowly-applicable than it actually
is.
For an extreme example of this, we can look at the SYS_TEXT_BASE symbol
in the Das U-Boot project (version 2019.10), which also uses Kconfig. (I
unfortunately could not find an illustrative example in Linux.) This
config option specifies the load address of the built binary and, as
such, is applicable to basically every configuration possible. And yet,
without this patch, its help text is as follows:
Symbol: SYS_TEXT_BASE [=]
Type : hex
Prompt: U-Boot base address
Location:
-> ARM architecture
Prompt: Text Base
Location:
-> Boot images
Defined at arch/arm/mach-aspeed/Kconfig:9
Depends on: ARM [=n] && ARCH_ASPEED [=n]
The help text indicates that the option is applicable only for a
specific unselected architecture (aspeed), because that architecture's
promptless definition (which just sets a default value), happens to be
the first one seen. No definition or dependency information is printed
for either of the two prompts listed.
Because source locations and dependencies are fundamentally properties
of definitions and not of symbols, we should treat them as such. This
patch brings back the pre-bcdedcc1afd6 behavior for definitions with
prompts but also separately prints the location and dependencies of
those without prompts, solving the original problem in a different way.
With this change, our SYS_TEXT_BASE example becomes
Symbol: SYS_TEXT_BASE [=]
Type : hex
Defined at arch/arm/mach-stm32mp/Kconfig:83
Prompt: U-Boot base address
Depends on: ARM [=n] && ARCH_STM32MP [=n]
Location:
-> ARM architecture
Defined at Kconfig:532
Prompt: Text Base
Depends on: !NIOS2 [=n] && !XTENSA [=n] && !EFI_APP [=n]
Location:
-> Boot images
Defined at arch/arm/mach-aspeed/Kconfig:9
Depends on: ARM [=n] && ARCH_ASPEED [=n]
Defined at arch/arm/mach-socfpga/Kconfig:25
Depends on: ARM [=n] && ARCH_SOCFPGA [=n]
<snip>
Defined at board/sifive/fu540/Kconfig:15
Depends on: RISCV [=n] && TARGET_SIFIVE_FU540 [=n]
which is a much more accurate representation.
Note that there is one notable difference between what gets printed for
prompts after this change and what got printed before bcdedcc1af: the
"Depends on" line now accurately represents the prompt's dependencies
instead of conflating those with the prompt's visibility (which can
include extra conditions). See the patch later in this series titled
"kconfig: distinguish between dependencies and visibility in help text"
for more details and better handling of that nuance.
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
menu_add_prompt() is the only function that calls menu_add_prop() with
non-NULL prompt.
So, the code inside the if-conditional block of menu_add_prop() can be
moved to menu_add_prompt().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
In menu_finalize(), the dependency of a menu entry is propagated
downwards.
For the 'menu', parent->dep and parent->prompt->visible.expr have
the same expression. Both accumulate the 'depends on' of itself and
upper menu entries.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This reverts commit ba6ff60d5e ("kconfig: don't emit warning upon
rootmenu's prompt redefinition").
At that time, rootmenu.prompt was always set first, then it was set
again if a "mainmenu" statement was specified in the Kconfig file.
This is no longer the case since commit 0724a7c32a ("kconfig: Don't
leak main menus during parsing"). Remove the unneeded check.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
All files in lxdialog/ are licensed under GPL-2.0+, and the rest are
under GPL-2.0. I added GPL-2.0 tags to test scripts in tests/.
Documentation/process/license-rules.rst does not suggest anything
about the flex/bison files. Because flex does not accept the C++
comment style at the very top of a file, I used the C style for
zconf.l, and so for zconf.y for consistency.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
For the keywords "modules", "defconfig_list", and "allnoconfig_y",
the lexer should pass specific tokens instead of generic T_WORD.
This simplifies both the lexer and the parser.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Over time, the use of the flag SYMBOL_AUTO changed from initially
marking three automatically generated symbols ARCH, KERNELRELEASE and
UNAME_RELEASE to today's effect of protecting symbols from being
written out.
Currently, only symbols of type CHOICE and those with option
defconf_list set have that flag set.
Reflect that change in semantics in the flag's name.
Signed-off-by: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
To get access to environment variables, Kconfig needs to define a
symbol using "option env=" syntax. It is tedious to add a symbol entry
for each environment variable given that we need to define much more
such as 'CC', 'AS', 'srctree' etc. to evaluate the compiler capability
in Kconfig.
Adding '$' for symbol references is grammatically inconsistent.
Looking at the code, the symbols prefixed with 'S' are expanded by:
- conf_expand_value()
This is used to expand 'arch/$ARCH/defconfig' and 'defconfig_list'
- sym_expand_string_value()
This is used to expand strings in 'source' and 'mainmenu'
All of them are fixed values independent of user configuration. So,
they can be changed into the direct expansion instead of symbols.
This change makes the code much cleaner. The bounce symbols 'SRCARCH',
'ARCH', 'SUBARCH', 'KERNELVERSION' are gone.
sym_init() hard-coding 'UNAME_RELEASE' is also gone. 'UNAME_RELEASE'
should be replaced with an environment variable.
ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced
without '$' prefix.
The new syntax is addicted by Make. The variable reference needs
parentheses, like $(FOO), but you can omit them for single-letter
variables, like $F. Yet, in Makefiles, people tend to use the
parenthetical form for consistency / clarification.
At this moment, only the environment variable is supported, but I will
extend the concept of 'variable' later on.
The variables are expanded in the lexer so we can simplify the token
handling on the parser side.
For example, the following code works.
[Example code]
config MY_TOOLCHAIN_LIST
string
default "My tools: CC=$(CC), AS=$(AS), CPP=$(CPP)"
[Result]
$ make -s alldefconfig && tail -n 1 .config
CONFIG_MY_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E"
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
The localization support is broken and appears unused.
There is no google hits on the update-po-config target.
And there is no recent (5 years) activity related to the localization.
So lets just drop this as it is no longer used.
Suggested-by: Ulf Magnusson <ulfalizer@gmail.com>
Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Surprisingly or not, disabling a CONFIG option (which is assumed to
be unneeded) may be not so trivial. Especially it is not trivial, when
this CONFIG option is selected by a dozen of other configs. Before the
moment commit 1ccb271433 ("kconfig: make "Selected by:" and
"Implied by:" readable") popped up in v4.16-rc1, it was an absolute pain
to break down the "Selected by" reverse dependency expression in order
to identify all those configs which select (IOW *do not allow
disabling*) a certain feature (assumed to be not needed).
This patch tries to make one step further by putting at users'
fingertips the revdep top level OR sub-expressions grouped/clustered by
the tristate value they evaluate to. This should allow the users to
directly concentrate on and tackle the _active_ reverse dependencies.
To give some numbers and quantify the complexity of certain reverse
dependencies, assuming commit 617aebe6a9 ("Merge tag
'usercopy-v4.16-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux"), ARCH=arm64
and vanilla arm64 defconfig, here is the top 10 CONFIG options with
the highest amount of top level "||" sub-expressions/tokens that make
up the final "Selected by" reverse dependency expression.
| Config | All revdep | Active revdep |
|-------------------|------------|---------------|
| REGMAP_I2C | 212 | 9 |
| CRC32 | 167 | 25 |
| FW_LOADER | 128 | 5 |
| MFD_CORE | 124 | 9 |
| FB_CFB_IMAGEBLIT | 114 | 2 |
| FB_CFB_COPYAREA | 111 | 2 |
| FB_CFB_FILLRECT | 110 | 2 |
| SND_PCM | 103 | 2 |
| CRYPTO_HASH | 87 | 19 |
| WATCHDOG_CORE | 86 | 6 |
The story behind the above is that users need to visually
review/evaluate 212 expressions which *potentially* select REGMAP_I2C
in order to identify the expressions which *actually* select REGMAP_I2C,
for a particular ARCH and for a particular defconfig used.
To make this experience smoother, change the way reverse dependencies
are displayed to the user from [1] to [2].
[1] Old representation of DMA_ENGINE_RAID:
Selected by:
- AMCC_PPC440SPE_ADMA [=n] && DMADEVICES [=y] && (440SPe || 440SP)
- BCM_SBA_RAID [=m] && DMADEVICES [=y] && (ARM64 [=y] || ...
- FSL_RAID [=n] && DMADEVICES [=y] && FSL_SOC && ...
- INTEL_IOATDMA [=n] && DMADEVICES [=y] && PCI [=y] && X86_64
- MV_XOR [=n] && DMADEVICES [=y] && (PLAT_ORION || ARCH_MVEBU [=y] ...
- MV_XOR_V2 [=y] && DMADEVICES [=y] && ARM64 [=y]
- XGENE_DMA [=n] && DMADEVICES [=y] && (ARCH_XGENE [=y] || ...
- DMATEST [=n] && DMADEVICES [=y] && DMA_ENGINE [=y]
[2] New representation of DMA_ENGINE_RAID:
Selected by [y]:
- MV_XOR_V2 [=y] && DMADEVICES [=y] && ARM64 [=y]
Selected by [m]:
- BCM_SBA_RAID [=m] && DMADEVICES [=y] && (ARM64 [=y] || ...
Selected by [n]:
- AMCC_PPC440SPE_ADMA [=n] && DMADEVICES [=y] && (440SPe || ...
- FSL_RAID [=n] && DMADEVICES [=y] && FSL_SOC && ...
- INTEL_IOATDMA [=n] && DMADEVICES [=y] && PCI [=y] && X86_64
- MV_XOR [=n] && DMADEVICES [=y] && (PLAT_ORION || ARCH_MVEBU [=y] ...
- XGENE_DMA [=n] && DMADEVICES [=y] && (ARCH_XGENE [=y] || ...
- DMATEST [=n] && DMADEVICES [=y] && DMA_ENGINE [=y]
Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This commit splits out the special E_OR handling ('-' instead of '||')
into a dedicated helper expr_print_revdev().
Restore the original expr_print() prior to commit 1ccb271433
("kconfig: make "Selected by:" and "Implied by:" readable").
This makes sense because:
- We need to chop those expressions only when printing the reverse
dependency, and only when E_OR is encountered
- Otherwise, it should be printed as before, so fall back to
expr_print()
This also improves the behavior; for a single line, it was previously
displayed in the same line as "Selected by", like this:
Selected by: A [=n] && B [=n]
This will be displayed in a new line, consistently:
Selected by:
- A [=n] && B [=n]
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
The 'defconfig_list' is a weird attribute. If the '.config' is
missing, conf_read_simple() iterates over all visible defaults,
then it uses the first one for which fopen() succeeds.
config DEFCONFIG_LIST
string
depends on !UML
option defconfig_list
default "/lib/modules/$UNAME_RELEASE/.config"
default "/etc/kernel-config"
default "/boot/config-$UNAME_RELEASE"
default "$ARCH_DEFCONFIG"
default "arch/$ARCH/defconfig"
However, like other symbols, the first visible default is always
written out to the .config file. This might be different from what
has been actually used.
For example, on my machine, the third one "/boot/config-$UNAME_RELEASE"
is opened, like follows:
$ rm .config
$ make oldconfig 2>/dev/null
scripts/kconfig/conf --oldconfig Kconfig
#
# using defaults found in /boot/config-4.4.0-112-generic
#
*
* Restart config...
*
*
* IRQ subsystem
*
Expose irq internals in debugfs (GENERIC_IRQ_DEBUGFS) [N/y/?] (NEW)
However, the resulted .config file contains the first one since it is
visible:
$ grep CONFIG_DEFCONFIG_LIST .config
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
In order to stop confusing people, prevent this CONFIG option from
being written to the .config file.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Reverse dependency expressions can get rather unwieldy, especially if
a symbol is selected by more than a handful of other symbols. I.e. it's
possible to have near endless expressions like:
A && B && !C || D || F && (G || H) || [...]
Chop these expressions into actually readable chunks:
- A && B && !C
- D
- F && (G || H)
- [...]
I.e. transform the top level OR tokens into newlines and prepend each
line with a minus. This makes the "Selected by:" and "Implied by:" blurb
much easier to read. This is done only if there is more than one top
level OR. "Depends on:" and "Range :" were deliberately left as they are.
Based on idea from Paul Bolle.
Suggested-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
It is not obvious that the last two cases refer to menus and ifs,
respectively, in the conditional that sets 'parentdep'.
Automatic submenu creation is done later, so the parent can't be a
symbol here.
No functional changes. Only comments added.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
It is not obvious that this might refer to an 'if', making the code
pretty cryptic:
if (menu->list && (!menu->prompt || !menu->prompt->text)) {
Kconfig keeps the 'if' menu nodes even after flattening. Reflect that in
the example to be accurate.
No functional changes. Only comments added.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
It's easy to miss that choices are special-cased to pass on their mode
as the parent dependency.
No functional changes. Only comments added.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Not obvious, especially if you don't already know how choices are
implemented.
No functional changes. Only comments added.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
No more users of this keyword. Drop it according to the notice by
commit 6341e62b21 ("kconfig: use bool instead of boolean for type
definition attributes").
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
menu_end_entry() is empty and completely unused as far as I can tell:
$ git log -G menu_end_entry --oneline
a02f057 [PATCH] kconfig: improve error handling in the parser
1da177e Linux-2.6.12-rc2
Last one is the initial Git commit, where menu_end_entry() is empty as
well. I couldn't find anything that redefined it on Google either.
It might be a debugging helper for setting a breakpoint after each
config, menuconfig, and comment is parsed. IMO it hurts more than it
helps in that case by making the parsing code look more complicated at a
glance than it really is, and I suspect it doesn't get used much.
Tested by running the Kconfiglib test suite, which indirectly verifies
that the .config files generated by the C implementation for each
defconfig file in the kernel stays the same.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
It's tricky to figure out what it does (and how) without staring at the
code for a long time. Document it to make it more transparent.
No functional changes. Only comments added.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
When propagating dependencies from parents after parsing, an expression
node is allocated if the parent symbol is a 'choice'. This node was
never freed.
Outline of leak:
if (sym && sym_is_choice(sym)) {
...
*Allocate (in this case only)*
parentdep = expr_alloc_symbol(sym);
} else if (parent->prompt)
parentdep = parent->prompt->visible.expr;
else
parentdep = parent->dep;
for (menu = parent->list; menu; menu = menu->next) {
...
*Copy*
basedep = expr_alloc_and(expr_copy(parentdep), basedep);
...
}
*parentdep lost if the parent is a choice!*
Fix by freeing 'parentdep' after the loop if the parent symbol is a
choice. Note that this only frees the expression node and not the choice
symbol itself.
Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:
LEAK SUMMARY:
definitely lost: 1,608 bytes in 67 blocks
...
Summary after the fix:
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
...
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
expr_trans_compare() always allocates and returns a new expression,
giving the following leak outline:
...
*Allocate*
basedep = expr_trans_compare(basedep, E_UNEQUAL, &symbol_no);
...
for (menu = parent->next; menu; menu = menu->next) {
...
*Copy*
dep2 = expr_copy(basedep);
...
*Free copy*
expr_free(dep2);
}
*basedep lost!*
Fix by freeing 'basedep' after the loop.
Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:
LEAK SUMMARY:
definitely lost: 344,376 bytes in 14,349 blocks
...
Summary after the fix:
LEAK SUMMARY:
definitely lost: 44,448 bytes in 1,852 blocks
...
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Kconfig currently doesn't handle 'm' appearing in a Kconfig file before
the modules symbol is defined (the symbol with 'option modules'). The
problem is the following code, which runs during parsing:
/* change 'm' into 'm' && MODULES */
if (e->left.sym == &symbol_mod)
return expr_alloc_and(e, expr_alloc_symbol(modules_sym));
If the modules symbol has not yet been defined, modules_sym is NULL,
giving an invalid expression.
Here is a test file where both BEFORE_1 and BEFORE_2 trigger a segfault.
If the modules symbol is removed, all symbols trigger segfaults.
config BEFORE_1
def_tristate y if m
if m
config BEFORE_2
def_tristate y
endif
config MODULES
def_bool y
option modules
config AFTER_1
def_tristate y if m
if m
config AFTER_2
def_tristate y
endif
Fix the issue by rewriting 'm' in menu_finalize() instead. This function
runs after parsing and is the proper place to do it. The following
existing code in conf_parse() in zconf.y ensures that the modules symbol
exists at that point:
if (!modules_sym)
modules_sym = sym_find( "n" );
...
menu_finalize(&rootmenu);
The following tests were done to ensure no functional changes for
configurations that don't reference 'm' before the modules symbol:
- zconfdump(stdout) was run with ARCH=x86 and ARCH=arm before
and after the change and verified to produce identical output.
This function prints all symbols, choices, and menus together
with their properties and their dependency expressions. A
rewritten 'm' appears as 'm && MODULES'.
A small annoyance is that the assert(len != 0) in xfwrite()
needs to be disabled in order to use zconfdump(), because it
chokes on e.g. 'default ""'.
- The Kconfiglib test suite was run to indirectly verify that
alldefconfig, allyesconfig, allnoconfig, and all defconfigs in
the kernel still generate the same final .config.
- Valgrind was used to check for memory errors and (new) memory
leaks.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
menu_finalize() is one of the more opaque parts of Kconfig, and I need
to make some changes to it to fix an issue related to modules. Add some
comments related to expression rewriting and dependency propagation as a
review aid. They will also help other people trying to understand the
code.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
More directly describes the only thing it does.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This will catch mistakes like in the following real-world example, where
a "CONFIG_" prefix snuck in, making an undefined symbol the default:
choice
prompt "Compiler optimization level"
default CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE
config CC_OPTIMIZE_FOR_PERFORMANCE
...
config CC_OPTIMIZE_FOR_SIZE
...
endchoice
This now prints the following warning:
init/Kconfig:1036:warning: choice default symbol 'CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE' is not contained in the choice
Cases where the default symbol belongs to the wrong choice are also
detected.
(The mistake is harmless here: Since the default symbol is not visible,
the choice falls back on using the first visible symbol as the default,
which is CC_OPTIMIZE_FOR_PERFORMANCE, as intended.)
Discovered while playing around with Kconfiglib
(https://github.com/ulfalizer/Kconfiglib).
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The "imply" keyword is a weak version of "select" where the target
config symbol can still be turned off, avoiding those pitfalls that come
with the "select" keyword.
This is useful e.g. with multiple drivers that want to indicate their
ability to hook into a secondary subsystem while allowing the user to
configure that subsystem out without also having to unset these drivers.
Currently, the same effect can almost be achieved with:
config DRIVER_A
tristate
config DRIVER_B
tristate
config DRIVER_C
tristate
config DRIVER_D
tristate
[...]
config SUBSYSTEM_X
tristate
default DRIVER_A || DRIVER_B || DRIVER_C || DRIVER_D || [...]
This is unwieldy to maintain especially with a large number of drivers.
Furthermore, there is no easy way to restrict the choice for SUBSYSTEM_X
to y or n, excluding m, when some drivers are built-in. The "select"
keyword allows for excluding m, but it excludes n as well. Hence
this "imply" keyword. The above becomes:
config DRIVER_A
tristate
imply SUBSYSTEM_X
config DRIVER_B
tristate
imply SUBSYSTEM_X
[...]
config SUBSYSTEM_X
tristate
This is much cleaner, and way more flexible than "select". SUBSYSTEM_X
can still be configured out, and it can be set as a module when none of
the drivers are configured in or all of them are modular.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <john.stultz@linaro.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Cc: Paul Bolle <pebolle@tiscali.nl>
Cc: linux-kbuild@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: Michal Marek <mmarek@suse.com>
Cc: Edward Cree <ecree@solarflare.com>
Link: http://lkml.kernel.org/r/1478841010-28605-2-git-send-email-nicolas.pitre@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
menu_is_visible() is a bool function and should use boolean return
values. "no" is a tristate value which happens to also have a value
of 0, but we should nevertheless use the right symbol for it.
This is a very minor cleanup with no semantic change.
Fixes: 86e187ff9 ("kconfig: add an option to determine a menu's visibility")
Cc: Arnaud Lacombe <lacombar@gmail.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Michal Marek <mmarek@suse.com>
Warning:
In file included from scripts/kconfig/zconf.tab.c:2537:0:
scripts/kconfig/menu.c: In function ‘get_symbol_str’:
scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in this function [-Wmaybe-uninitialized]
jump->offset = strlen(r->s);
Simplifies the test logic because (head && local) means (jump != 0)
and makes GCC happy when checking if the jump pointer was initialized.
Signed-off-by: Peter Kümmel <syntheticpp@gmx.net>
Signed-off-by: Michal Marek <mmarek@suse.cz>
"make allnoconfig" exists to ease testing of minimal configurations.
Documentation/SubmitChecklist includes a note to test with allnoconfig.
This helps catch missing dependencies on common-but-not-required
functionality, which might otherwise go unnoticed.
However, allnoconfig still leaves many symbols enabled, because they're
hidden behind CONFIG_EMBEDDED or CONFIG_EXPERT. For instance, allnoconfig
still has CONFIG_PRINTK and CONFIG_BLOCK enabled, so drivers don't
typically get build-tested with those disabled.
To address this, introduce a new Kconfig option "allnoconfig_y", used on
symbols which only exist to hide other symbols. Set it on CONFIG_EMBEDDED
(which then selects CONFIG_EXPERT). allnoconfig will then disable all the
symbols hidden behind those.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The struct gstr has a capacity that may differ from the actual string length.
However, a string manipulation in the function search_conf made the assumption
that it is the same, which led to messing up some search results, especially
when the content of the gstr in use had not yet reached at least 63 chars.
Signed-off-by: Martin Walch <walch.martin@web.de>
Acked-by: Wang YanQing <udknight@gmail.com>
Acked-by: Benjamin Poirier <bpoirier@suse.de>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Each symbol must have exactly one type assigned. However, if a symbol happens
to have two different types assigned at runtime, a warning is printed and the
first type is preserved while the second type is being ignored.
The warning message says
type of <symbol name> redefined from <first type> to <second type>
which may be misleading as it may create the impression that the second type
replaces the first type.
This patch clarifies this by changing the warning to
ignoring type redefinition of <symbol name> from <first type> to <second type>
Signed-off-by: Martin Walch <walch.martin@web.de>
Acked-by: Wang YanQing <udknight@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This fixes lots of typos in comments and strings.
It also updates the documentation strings in mconf to reflect the changes in
the user interface from the two commits
6364fd0cb1
menuconfig: Add Save/Load buttons
1bdbac478a
menuconfig: Get rid of the top-level entries for "Load an Alternate/Save an Alternate"
And it updates the layout of the example search result, i. e. moves down the
"Defined at" and "Depends on" lines and adds a symbol state ([=n]) to the
symbol in the "Selected by" line.
Furthermore, the help texts now should fit in 80 columns again when viewed
in mconf.
Signed-off-by: Martin Walch <walch.martin@web.de>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Wang YanQing <udknight@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Previously, it was possible to have more than one symbol with the
'option modules' attached to them, although only the last one would
in fact control tristates.
Since this does not make much sense, only allow at most one symbol to
control tristates.
Note: it is still possible to have more than one symbol that control
tristates, but indirectly:
config MOD1
bool "mod1"
select MODULES
config MOD2
bool "mod2"
select MODULES
config MODULES
bool
option modules
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Currently, the 'MODULES' symbol is hard-coded to be the default symbol
that enables/disables tristates, if no other symbol was declared with
'option modules'.
While this used to be needed for the Linux kernel, we now have an
explicit 'option modules' attached to the 'MODULES' symbol (since
cset 11097a036), so we no longer need to special-case it in the
kconfig code.
Furthermore, kconfig is extensively used out of the Linux kernel, and
other projects may have another meaning for a symbol named 'MODULES'.
This patch changes the way we enable/disable tristates: if a symbol was
found with 'option modules' attached to it, then that symbol controls
enabling tristates. Otherwise, tristates are disabled, even if a symbol
named 'MODULES' exists.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Pull kconfig updates from Michal Marek:
- dependency solver fix for make defconfig
- randconfig fixes, one of which had to be reverted again
- more user-friendly sorting of search results
- hex and range keywords support longs
- fix for [mn]conf not to rely on particular behavior of the LINES and
COLS variables
- cleanup of magic constants in kconfig/lxdialog
- [mn]conf formatting fixes
- fix for scripts/config's help text in out-of-tree usage (under a
different name)
* 'kconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
kconfig: allow "hex" and "range" to support longs
Revert "kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG"
kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG
kconfig: loop as long as we changed some symbols in randconfig
kconfig/[mn]conf: make it explicit in the search box that a regexp is possible
kconfig: sort found symbols by relevance
kconfig/conf: print the seed used to initialise the RNG for randconfig
kconfig/conf: accept a base-16 seed for randconfig
kconfig/conf: fix randconfig setting multiple symbols in a choice
scripts/config: replace hard-coded script name by a dynamic value
mconf/nconf: mark empty menus/menuconfigs different from non-empty ones
nconf: use function calls instead of ncurses' variables LINES and COLS
mconf: use function calls instead of ncurses' variables LINES and COLS
kconfig/lxdialog: handle newline characters in print_autowrap()
kconfig/lxdialog: Use new mininimum resize definitions in conf_choice()
kconfig/lxdialog: Add definitions for mininimum (re)size values
kconfig: Fix defconfig when one choice menu selects options that another choice menu depends on
Submenus are sometimes empty and it would be nice if there is
something that notifies us that we should not expect any content
_before_ we enter a submenu.
A new function menu_is_empty() was introduced and empty menus and
menuconfigs are now marked by "----" as opposed to non-empty ones that
are marked by "--->".
This scheme was suggested by "Yann E. MORIN" <yann.morin.1998@free.fr>.
Signed-off-by: Dirk Gouders <dirk@gouders.net>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
menu_add_prop() applies upper menus' visibilities to actual prompts
by AND-ing the prompts visibilities with the upper menus ones.
This creates a further reference to the menu's visibilities and when
the expression reduction functions do their work, they may remove or
modify expressions that have multiple references, thus causing
unpredictable side-effects.
The following example Kconfig constructs a case where this causes
problems: a menu and a prompt which's visibilities depend on the same
symbol. When invoking mconf with this Kconfig and pressing "Z" we
see a problem caused by a free'd expression still referenced by the
menu's visibility:
------------------------------------------------------------------------
mainmenu "Kconfig Testing Configuration"
config VISIBLE
def_bool n
config Placeholder
bool "Place holder"
menu "Invisible"
visible if VISIBLE
config TEST_VAR
bool "Test option" if VISIBLE
endmenu
------------------------------------------------------------------------
This patch fixes this problem by creating copies of the menu's
visibility expressions before AND-ing them with the prompt's one.
Signed-off-by: Dirk Gouders <dirk@gouders.net>
[yann.morin.1998@free.fr: move variable into its block-scope,
keep lines <80 chars, typo]
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Searching for PPC_EFIKA results in a segmentation fault, and it's
because get_symbol_prop() returns NULL.
In this case CONFIG_PPC_EFIKA is defined in arch/powerpc/platforms/
52xx/Kconfig, so it won't be parsed if ARCH!=PPC, but menuconfig knows
this symbol when it parses sound/soc/fsl/Kconfig:
config SND_MPC52xx_SOC_EFIKA
tristate "SoC AC97 Audio support for bbplan Efika and STAC9766"
depends on PPC_EFIKA
This bug was introduced by commit bcdedcc1af ("menuconfig: print more
info for symbol without prompts").
Reported-and-tested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Li Zefan <lizefan@huawei.com>
Tested-by: Libo Chen <libo.chen@huawei.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When we search a config symbol, if it has no prompt the position of this
symbol in the Kconfig file and it's dependencies are not printed. This
can be inconvenient, especially when it's set to n and we want to find out
why.
the following is an example:
before:
Symbol: GENERIC_SMP_IDLE_THREAD [=y]
Type : boolean
Selected by: X86 [=y]
after:
Symbol: GENERIC_SMP_IDLE_THREAD [=y]
Type : boolean
Defined at arch/Kconfig:213
Selected by: X86 [=y]
Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
Signed-off-by: Libo Chen <libo.chen@huawei.com>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
sys/queue.h and CIRCLEQ in particular have proven to cause portability
problems (reported on Debian Sarge, Cygwin and FreeBSD)
Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Tested-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Michal Marek <mmarek@suse.cz>
