12 May, 2020
1 commit
-
I am not a big fan of doing assignment in a return statement.
Split it into two lines.Signed-off-by: Masahiro Yamada
07 Jan, 2020
8 commits
-
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] &&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] &&Signed-off-by: Thomas Hebb
Signed-off-by: Masahiro Yamada -
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 bcdedcc1afd6 ("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 bcdedcc1afd, 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
Signed-off-by: Masahiro Yamada -
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 bcdedcc1afd6 ("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 becomesSymbol: 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]
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 bcdedcc1afd6: 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
Signed-off-by: Masahiro Yamada -
prop_alloc() is only called from menu_add_prop(). Squash it.
Signed-off-by: Masahiro Yamada
-
This function no longer uses the 'prompt' argument.
Signed-off-by: Masahiro Yamada
-
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
-
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
-
This reverts commit ba6ff60d5eb4 ("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 0724a7c32a54 ("kconfig: Don't
leak main menus during parsing"). Remove the unneeded check.Signed-off-by: Masahiro Yamada
28 Dec, 2018
1 commit
-
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
21 Dec, 2018
1 commit
-
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
18 Jul, 2018
1 commit
-
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
Signed-off-by: Masahiro Yamada
29 May, 2018
1 commit
-
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
Reviewed-by: Kees Cook
28 May, 2018
1 commit
-
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
Suggested-by: Masahiro Yamada
Signed-off-by: Sam Ravnborg
Signed-off-by: Masahiro Yamada
26 Mar, 2018
2 commits
-
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 1ccb27143360 ("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 617aebe6a97e ("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
Signed-off-by: Eugeniu Rosca
Reviewed-by: Petr Vorel
Reviewed-by: Ulf Magnusson
Signed-off-by: Masahiro Yamada -
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 1ccb27143360
("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
Reviewed-by: Petr Vorel
02 Mar, 2018
1 commit
-
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
Reviewed-by: Ulf Magnusson
25 Jan, 2018
1 commit
-
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
Signed-off-by: Petr Vorel
Signed-off-by: Masahiro Yamada
22 Jan, 2018
2 commits
-
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
Signed-off-by: Masahiro Yamada -
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
Signed-off-by: Masahiro Yamada
21 Jan, 2018
7 commits
-
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
Signed-off-by: Masahiro Yamada -
Not obvious, especially if you don't already know how choices are
implemented.No functional changes. Only comments added.
Signed-off-by: Ulf Magnusson
Signed-off-by: Masahiro Yamada -
No more users of this keyword. Drop it according to the notice by
commit 6341e62b212a ("kconfig: use bool instead of boolean for type
definition attributes").Signed-off-by: Masahiro Yamada
Acked-by: Luis R. Rodriguez -
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-rc2Last 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
Signed-off-by: Masahiro Yamada -
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
Signed-off-by: Masahiro Yamada -
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
Signed-off-by: Masahiro Yamada -
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
Signed-off-by: Masahiro Yamada
15 Dec, 2017
3 commits
-
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 mif m
config BEFORE_2
def_tristate y
endifconfig MODULES
def_bool y
option modulesconfig AFTER_1
def_tristate y if mif m
config AFTER_2
def_tristate y
endifFix 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
Signed-off-by: Masahiro Yamada -
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
Signed-off-by: Masahiro Yamada -
More directly describes the only thing it does.
Signed-off-by: Ulf Magnusson
Signed-off-by: Masahiro Yamada
07 Dec, 2017
1 commit
-
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_PERFORMANCEconfig 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
Signed-off-by: Masahiro Yamada
16 Nov, 2016
1 commit
-
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
tristateconfig DRIVER_B
tristateconfig DRIVER_C
tristateconfig 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_Xconfig DRIVER_B
tristate
imply SUBSYSTEM_X[...]
config SUBSYSTEM_X
tristateThis 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
Acked-by: Richard Cochran
Acked-by: Thomas Gleixner
Acked-by: John Stultz
Reviewed-by: Josh Triplett
Cc: Paul Bolle
Cc: linux-kbuild@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: Michal Marek
Cc: Edward Cree
Link: http://lkml.kernel.org/r/1478841010-28605-2-git-send-email-nicolas.pitre@linaro.org
Signed-off-by: Thomas Gleixner
05 Jan, 2016
1 commit
-
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
Cc: Mauro Carvalho Chehab
Signed-off-by: Vegard Nossum
Signed-off-by: Michal Marek
25 Feb, 2015
1 commit
-
Signed-off-by: Michal Marek
28 Nov, 2014
1 commit
-
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
Signed-off-by: Michal Marek
10 Jun, 2014
1 commit
-
Signed-off-by: Masahiro Yamada
Signed-off-by: Michal Marek
08 Apr, 2014
1 commit
-
"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
Tested-by: Paul E. McKenney
Cc: Michal Marek
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
09 Oct, 2013
3 commits
-
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
Acked-by: Wang YanQing
Acked-by: Benjamin Poirier
Reviewed-by: "Yann E. MORIN"
Signed-off-by: "Yann E. MORIN" -
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 redefined from to
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 from to
Signed-off-by: Martin Walch
Acked-by: Wang YanQing
Reviewed-by: "Yann E. MORIN"
Signed-off-by: "Yann E. MORIN" -
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 commits6364fd0cb1e4c7f72b974613e0cf5744ae4d2cb2
menuconfig: Add Save/Load buttons
1bdbac478a858d2aa73a6784c7c2e09de0f6d06b
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
Reviewed-by: Jean Delvare
Reviewed-by: Wang YanQing
Signed-off-by: "Yann E. MORIN"
