The rule of mainmenu_stmt does not have debug print of zconf_lineno(),
but if it had, it would print a wrong line number for the same reason
as commit b2d00d7c61 ("kconfig: fix line numbers for if-entries in
menu tree").
The mainmenu_stmt does not need to eat following empty lines because
they are reduced to common_stmt.
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>
Each symbol has a property of type P_SYMBOL since commit
59e89e3ddf (kconfig: save location of config symbols).
Handle those properties in print_symbol().
Further, place a pointer to print_symbol() in the comment above the
list of known property type.
Signed-off-by: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The line numers for if-entries in the menu tree are off by one or more
lines which is confusing when debugging for correctness of unrelated changes.
According to the git log, commit a02f0570ae (kconfig: improve
error handling in the parser) was the last one that changed that part
of the parser and replaced
"if_entry: T_IF expr T_EOL"
by
"if_entry: T_IF expr nl"
but the commit message does not state why this has been done.
When reverting that part of the commit, only the line numers are
corrected (checked with cdebug = DEBUG_PARSE in zconf.y), otherwise
the menu tree remains unchanged (checked with zconfdump() enabled in
conf.c).
An example for the corrected line numbers:
drivers/soc/Kconfig:15:source drivers/soc/tegra/Kconfig
drivers/soc/tegra/Kconfig:4:if
drivers/soc/tegra/Kconfig:6:if
changes to:
drivers/soc/Kconfig:15:source drivers/soc/tegra/Kconfig
drivers/soc/tegra/Kconfig:1:if
drivers/soc/tegra/Kconfig:4:if
Signed-off-by: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The previous commit added variable and user-defined function. They
work similarly in the sense that the evaluation is deferred until
they are used.
This commit adds another type of variable, simply expanded variable,
as we see in Make.
The := operator defines a simply expanded variable, expanding the
righthand side immediately. This works like traditional programming
language variables.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Now, we got a basic ability to test compiler capability in Kconfig.
config CC_HAS_STACKPROTECTOR
def_bool $(shell,($(CC) -Werror -fstack-protector -E -x c /dev/null -o /dev/null 2>/dev/null) && echo y || echo n)
This works, but it is ugly to repeat this long boilerplate.
We want to describe like this:
config CC_HAS_STACKPROTECTOR
bool
default $(cc-option,-fstack-protector)
It is straight-forward to add a new function, but I do not like to
hard-code specialized functions like that. Hence, here is another
feature, user-defined function. This works as a textual shorthand
with parameterization.
A user-defined function is defined by using the = operator, and can
be referenced in the same way as built-in functions. A user-defined
function in Make is referenced like $(call my-func,arg1,arg2), but I
omitted the 'call' to make the syntax shorter.
The definition of a user-defined function contains $(1), $(2), etc.
in its body to reference the parameters. It is grammatically valid
to pass more or fewer arguments when calling it. We already exploit
this feature in our makefiles; scripts/Kbuild.include defines cc-option
which takes two arguments at most, but most of the callers pass only
one argument.
By the way, a variable is supported as a subset of this feature since
a variable is "a user-defined function with zero argument". In this
context, I mean "variable" as recursively expanded variable. I will
add a different flavored variable in the next commit.
The code above can be written as follows:
[Example Code]
success = $(shell,($(1)) >/dev/null 2>&1 && echo y || echo n)
cc-option = $(success,$(CC) -Werror $(1) -E -x c /dev/null -o /dev/null)
config CC_HAS_STACKPROTECTOR
def_bool $(cc-option,-fstack-protector)
[Result]
$ make -s alldefconfig && tail -n 1 .config
CONFIG_CC_HAS_STACKPROTECTOR=y
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
If "mainmenu" is not specified, "Linux Kernel Configuration" is used
as a default prompt.
Given that Kconfig is used in other projects than Linux, let's use
a more generic prompt, "Main menu".
Suggested-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Now that environments are expanded in the lexer, conf_parse() does
not need to expand them explicitly.
The hack introduced by commit 0724a7c32a ("kconfig: Don't leak
main menus during parsing") can go away.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.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>
The named choice is not used in the kernel tree, but if it were used,
it would not be freed.
The intention of the named choice can be seen in the log of
commit 5a1aa8a1af ("kconfig: add named choice group").
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
We already have xmalloc(), xcalloc(), and xrealloc((). Add xstrdup()
as well to save tedious error handling.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Blank help texts are probably either a typo, a Kconfig misunderstanding,
or some kind of half-committing to adding a help text (in which case a
TODO comment would be clearer, if the help text really can't be added
right away).
Best to flag them, IMO.
Example warning:
drivers/mmc/host/Kconfig:877: warning: 'MMC_TOSHIBA_PCI' defined with blank help text
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Flex and Bison provide an option to change the prefix of globally-
visible symbols. This is useful to link multiple lexers and/or
parsers into the same executable. However, Kconfig (and any other
host programs in kernel) uses a single lexer and parser. I do not
see a good reason to change the default 'yy' prefix.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Avoids mistakes like in the following real-world example, where only the
final help string ("Say Y...") was used. This particular example was
fixed in commit 561b29e4ec ("media: fix media Kconfig help syntax
issues").
config DVB_NETUP_UNIDVB
...
select DVB_CXD2841ER if MEDIA_SUBDRV_AUTOSELECT
---help---
Support for NetUP PCI express Universal DVB card.
help
Say Y when you want to support NetUP Dual Universal DVB card
...
This now prints the following warning:
drivers/media/pci/netup_unidvb:13: warning: 'DVB_NETUP_UNIDVB' defined with more than one help text -- only the last one will be used
Also free() any extra help strings.
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>
If a 'mainmenu' entry appeared in the Kconfig files, two things would
leak:
- The 'struct property' allocated for the default "Linux Kernel
Configuration" prompt.
- The string for the T_WORD/T_WORD_QUOTE prompt after the
T_MAINMENU token, allocated on the heap in zconf.l.
To fix it, introduce a new 'no_mainmenu_stmt' nonterminal that matches
if there's no 'mainmenu' and adds the default prompt. That means the
prompt only gets allocated once regardless of whether there's a
'mainmenu' statement or not, and managing it becomes simple.
Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:
LEAK SUMMARY:
definitely lost: 344,568 bytes in 14,352 blocks
...
Summary after the fix:
LEAK SUMMARY:
definitely lost: 344,440 bytes in 14,350 blocks
...
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The following strings would leak before this change:
- option env="LEAKED"
- option defconfig_list="LEAKED"
These come in the form of T_WORD tokens and are always allocated on the
heap in zconf.l. Free them.
Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:
LEAK SUMMARY:
definitely lost: 344,616 bytes in 14,355 blocks
...
Summary after the fix:
LEAK SUMMARY:
definitely lost: 344,568 bytes in 14,352 blocks
...
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The 'source_stmt' nonterminal takes a 'prompt', which consists of either
a T_WORD or a T_WORD_QUOTE, both of which are always allocated on the
heap in zconf.l and need to have their associated strings freed. Free
them.
The existing code already makes sure to always copy the string, but add
a warning to sym_expand_string_value() to make it clear that the string
must be copied, just in case.
Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:
LEAK SUMMARY:
definitely lost: 387,504 bytes in 15,545 blocks
...
Summary after the fix:
LEAK SUMMARY:
definitely lost: 344,616 bytes in 14,355 blocks
...
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Prior to this fix, zconf.y did not free symbol names from zconf.l in
these contexts:
- After T_CONFIG ('config LEAKED')
- After T_MENUCONFIG ('menuconfig LEAKED')
- After T_SELECT ('select LEAKED')
- After T_IMPLY ('imply LEAKED')
- After T_DEFAULT in a choice ('default LEAKED')
All of these come in the form of T_WORD tokens, which always have their
associated string allocated on the heap in zconf.l and need to be freed.
Fix by introducing a new nonterminal 'nonconst_symbol' which takes a
T_WORD, fetches the symbol, and then frees the T_WORD string. The
already existing 'symbol' nonterminal works the same way but also
accepts T_WORD_QUOTE, corresponding to a constant symbol. T_WORD_QUOTE
should not be accepted in any of the contexts above, so the 'symbol'
nonterminal can't be reused here.
Fetching the symbol in 'nonconst_symbol' also removes a bunch of
sym_lookup() calls from actions.
Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:
LEAK SUMMARY:
definitely lost: 711,571 bytes in 37,756 blocks
...
Summary after the fix:
LEAK SUMMARY:
definitely lost: 387,504 bytes in 15,545 blocks
...
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Looks like a change to a comment in zconf.y was never committed, because
the updated version only appears it zconf.tab.c_shipped. Update the
comment in zconf.y to match.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
It turns out that gperf-3.1 changed types in the generated code in ways
that aren't even trivially detectable without having to generate a test-file.
It's just not worth using tools and libraries from clowns that don't
understand or care about compatibility. So get rid of gperf.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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>
Over the years I found it desirable to be able to use all sorts of
relations, not just (in)equality. And apparently I'm not the only one,
as there's at least one example in the tree where the programmer
assumed this would work (see DEBUG_UART_8250_WORD in
arch/arm/Kconfig.debug). Another possible use would e.g. be to fold the
two SMP/NR_CPUS prompts into one: SMP could be promptless, simply
depending on NR_CPUS > 1.
A (desirable) side effect of this change - resulting from numeric
values now necessarily being compared as numbers rather than as
strings - is that comparing hex values now works as expected: Other
than int ones (which aren't allowed to have leading zeroes), zeroes
following the 0x prefix made them compare unequal even if their values
were equal.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Masahiro Yamada
Dirk Gouders
Sam Ravnborg
Ulf Magnusson
Linus Torvalds
Nicolas Pitre
Jan Beulich