path: root/scripts/kconfig/zconf.l (follow)
AgeCommit message (Collapse)AuthorFilesLines
2019-02-13kconfig: rename zconf.l to lexer.lMasahiro Yamada1-470/+0
Use a more logical name. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-28kconfig: split the lexer out of zconf.yMasahiro Yamada1-0/+1
Compile zconf.lex.c independently of the other files. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-28kconfig: convert to SPDX License IdentifierMasahiro Yamada1-4/+4
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>
2018-12-28kconfig: remove keyword lookup table entirelyMasahiro Yamada1-84/+69
Commit 7a88488bbc23 ("[PATCH] kconfig: use gperf for kconfig keywords") introduced gperf for the keyword lookup. Then, commit bb3290d91695 ("Remove gperf usage from toolchain") killed the gperf use. As a result, the linear keyword search was left behind. If we do not use gperf, there is no reason to have the separate table of the keywords. Move all keywords back to the lexer. I also refactored the lexer to remove the COMMAND and PARAM states. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-22kconfig: update current_pos in the second lexerMasahiro Yamada1-5/+15
To simplify the generated lexer, let the hand-made lexer update the file name and line number for the parser. I tested this with DEBUG_PARSE, and confirmed the same file names and line numbers were dumped. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-22kconfig: switch to ASSIGN_VAL state in the second lexerMasahiro Yamada1-3/+9
To simplify the generated lexer, switch to the ASSIGN_VAL state in the hand-made lexer. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-22kconfig: stop associating kconf_id with yylvalMasahiro Yamada1-2/+0
The lexer has conventionally associated kconf_id data with yylval to carry additional information to the parser. No token is relying on this any more. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-22kconfig: stop supporting '.' and '/' in unquoted wordsMasahiro Yamada1-2/+2
In my understanding, special characters such as '.' and '/' are supported in unquoted words to use bare file paths in the "source" statement. With the previous commit surrounding all file paths with double quotes, we can drop this. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-22kconfig: use T_WORD instead of T_VARIABLE for variablesMasahiro Yamada1-2/+2
There is no grammatical ambiguity by using T_WORD for variables. The parser can distinguish variables from symbols from the context. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-22kconfig: use specific tokens instead of T_ASSIGN for assignmentsMasahiro Yamada1-3/+3
Currently, the lexer returns T_ASSIGN for all of =, :=, and += associating yylval with the flavor. I want to make the generated lexer as simple as possible. So, the lexer should convert keywords to tokens without thinking about the meaning. = -> T_EQUAL := -> T_COLON_EQUAL += -> T_PLUS_EQUAL Unfortunately, Kconfig uses = instead of == for the equal operator. So, the same token T_EQUAL is used for assignment and comparison. The parser can still distinguish them from the context. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-22kconfig: refactor scanning and parsing "option" propertiesMasahiro Yamada1-0/+3
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>
2018-12-15kconfig: warn no new line at end of fileMasahiro Yamada1-0/+4
It would be nice to warn if a new line is missing at end of file. We could do this by checkpatch.pl for arbitrary files, but new line is rather essential as a statement terminator in Kconfig. The warning message looks like this: kernel/Kconfig.preempt:60:warning: no new line at end of file Currently, kernel/Kconfig.preempt is the only file with no new line at end of file. Fix it. I know there are some false negative cases. For example, no warning is displayed when the last line contains some whitespaces/comments, but no new line. Yet, this commit works well for most cases. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-13kconfig: clean up EOF handling in the lexerMasahiro Yamada1-3/+2
A new file should always start in the INITIAL state. When the lexer bumps into EOF, the lexer must get back to the INITIAL state anyway. Remove the redundant <<EOF>> pattern in the PARAM state. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-13kconfig: fix ambiguous grammar in terms of new linesMasahiro Yamada1-0/+21
This commit decreases 8 shift/reduce conflicts. A certain amount of grammatical ambiguity comes from how to reduce excessive T_EOL tokens. Let's take a look at the example code below: 1 config A 2 bool "a" 3 4 depends on B 5 6 config B 7 def_bool y The line 3 is melt into "config_option_list", but the line 5 can be either a part of "config_option_list" or "common_stmt" by itself. Currently, the lexer converts '\n' to T_EOL verbatim. In Kconfig, a new line works as a statement terminator, but new lines in empty lines are not critical since empty lines (or lines that contain only whitespaces/comments) are just no-op. If the lexer simply discards no-op lines, the parser will not be bothered by excessive T_EOL tokens. Of course, this means we are shifting the complexity from the parser to the lexer, but it is much easier than tackling on shift/reduce conflicts. I introduced the second stage lexer to tweak the behavior. Discard T_EOL if the previous token is T_EOL or T_HELPTEXT. Two T_EOL tokens in a row is meaningless. T_HELPTEXT is a special token that is reduced without T_EOL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-13kconfig: refactor pattern matching in STRING stateMasahiro Yamada1-11/+3
Here, similar matching patters are duplicated in order to look ahead the '\n' character. If the next character is '\n', the lexer returns T_WORD_QUOTE because it must be prepared to return T_EOL at the next match. Use unput('\n') trick to reduce the code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-13kconfig: remove unneeded pattern matching to whitespacesMasahiro Yamada1-6/+0
Whitespaces are consumed in the COMMAND state anyway. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-13kconfig: fix memory leak when EOF is encountered in quotationMasahiro Yamada1-0/+2
An unterminated string literal followed by new line is passed to the parser (with "multi-line strings not supported" warning shown), then handled properly there. On the other hand, an unterminated string literal at end of file is never passed to the parser, then results in memory leak. [Test Code] ----------(Kconfig begin)---------- source "Kconfig.inc" config A bool "a" -----------(Kconfig end)----------- --------(Kconfig.inc begin)-------- config B bool "b\No new line at end of file ---------(Kconfig.inc end)--------- [Summary from Valgrind] Before the fix: LEAK SUMMARY: definitely lost: 16 bytes in 1 blocks ... After the fix: LEAK SUMMARY: definitely lost: 0 bytes in 0 blocks ... Eliminate the memory leak path by handling this case. Of course, such a Kconfig file is wrong already, so I will add an error message later. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-13kconfig: fix file name and line number of warn_ignored_character()Masahiro Yamada1-1/+1
Currently, warn_ignore_character() displays invalid file name and line number. The lexer should use current_file->name and yylineno, while the parser should use zconf_curname() and zconf_lineno(). This difference comes from that the lexer is always going ahead of the parser. The parser needs to look ahead one token to make a shift/reduce decision, so the lexer is requested to scan more text from the input file. This commit fixes the warning message from warn_ignored_character(). [Test Code] ----(Kconfig begin)---- / -----(Kconfig end)----- [Output] Before the fix: <none>:0:warning: ignoring unsupported character '/' After the fix: Kconfig:1:warning: ignoring unsupported character '/' Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-05-29kconfig: expand lefthand side of assignment statementMasahiro Yamada1-0/+7
Make expands the lefthand side of assignment statements. In fact, Kbuild relies on it since kernel makefiles mostly look like this: obj-$(CONFIG_FOO) += foo.o Do likewise in Kconfig. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-05-29kconfig: support append assignment operatorMasahiro Yamada1-0/+1
Support += operator. This appends a space and the text on the righthand side to a variable. The timing of the evaluation of the righthand side depends on the flavor of the variable. If the lefthand side was originally defined as a simple variable, the righthand side is expanded immediately. Otherwise, the expansion is deferred. Appending something to an undefined variable results in a recursive variable. To implement this, we need to remember the flavor of variables. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-05-29kconfig: support simply expanded variableMasahiro Yamada1-1/+2
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>
2018-05-29kconfig: support user-defined function and recursively expanded variableMasahiro Yamada1-2/+15
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>
2018-05-29kconfig: begin PARAM state only when seeing a command keywordMasahiro Yamada1-1/+1
Currently, any statement line starts with a keyword with TF_COMMAND flag. So, the following three lines are dead code. alloc_string(yytext, yyleng); zconflval.string = text; return T_WORD; If a T_WORD token is returned in this context, it will cause syntax error in the parser anyway. The next commit will support the assignment statement where a line starts with an arbitrary identifier. So, I want the lexer to switch to the PARAM state only when it sees a command keyword. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-05-29kconfig: reference environment variables directly and remove 'option env='Masahiro Yamada1-3/+64
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>
2018-03-26kconfig: use yylineno option instead of manual lineno incrementsMasahiro Yamada1-11/+9
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>
2018-03-26kconfig: detect recursive inclusion earlierMasahiro Yamada1-6/+8
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>
2018-03-26kconfig: remove duplicated file name and lineno of recursive inclusionMasahiro Yamada1-5/+4
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>
2018-03-03kconfig: fix line number in recursive inclusion error messageMasahiro Yamada1-8/+4
When recursive inclusion is detected, the line number of the last 'included from:' is wrong. [Test Case] Kconfig: -------->8-------- source "Kconfig2" -------->8-------- Kconfig2: -------->8-------- source "Kconfig3" -------->8-------- Kconfig3: -------->8-------- source "Kconfig" -------->8-------- [Result] $ make allyesconfig scripts/kconfig/conf --allyesconfig Kconfig Kconfig:1: recursive inclusion detected. Inclusion path: current file : 'Kconfig' included from: 'Kconfig3:1' included from: 'Kconfig2:1' included from: 'Kconfig:3' scripts/kconfig/Makefile:89: recipe for target 'allyesconfig' failed make[1]: *** [allyesconfig] Error 1 Makefile:512: recipe for target 'allyesconfig' failed make: *** [allyesconfig] Error 2 where we expect current file : 'Kconfig' included from: 'Kconfig3:1' included from: 'Kconfig2:1' included from: 'Kconfig:1' The 'iter->lineno+1' in the second fpinrtf() should be 'iter->lineno-1'. I refactored the code to merge the two fprintf() calls. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-02-10kconfig: add xrealloc() helperMasahiro Yamada1-1/+1
We already have xmalloc(), xcalloc(). Add xrealloc() as well to save tedious error handling. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-02-09kconfig: send error messages to stderrMasahiro Yamada1-12/+15
These messages should be directed to stderr. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-01-22kconfig: use default 'yy' prefix for lexer and parserMasahiro Yamada1-8/+8
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>
2015-08-19kconfig: warn of unhandled characters in Kconfig commandsAndreas Ruprecht1-9/+11
In Kconfig, definitions of options take the following form: "<COMMAND> <PARAM> <PARAM> ...". COMMANDs and PARAMs are treated slightly different by the underlying parser. While commit 2e0d737fc76f ("kconfig: don't silently ignore unhandled characters") introduced a warning for unsupported characters around PARAMs, it does not cover situations where a COMMAND has additional characters before it. This change makes Kconfig emit a warning if superfluous characters are found before COMMANDs. As the 'help' statement sometimes is written as '---help---', the '-' character would now also be regarded as unhandled and generate a warning. To avoid that, '-' is added to the list of allowed characters, and the token '---help---' is included in the zconf.gperf file. Reported-by: Valentin Rothberg <valentinrothberg@gmail.com> Signed-off-by: Andreas Ruprecht <andreas.ruprecht@fau.de> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com> Tested-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2015-06-15kconfig: allow use of relations other than (in)equalityJan Beulich1-0/+4
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>
2015-06-11kconfig: don't silently ignore unhandled charactersJan Beulich1-1/+6
At the very least we should tell people that what they wrote is not what the utility understands. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Michal Marek <mmarek@suse.cz>
2014-06-10kbuild: trivial - use tabs for code indent where possibleMasahiro Yamada1-2/+2
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2013-10-08kconfig: remove unused definition from scannerMartin Walch1-1/+0
The definition ws [ \n\t] is not used anywhere. Drop it to avoid confusion. As it is a dead definition, any changes in the resulting code generated by flex would be surprising (actually testing this showed that there are really no changes). So, there is no need to touch the existing zconf.lex.c_shipped. Signed-off-by: Martin Walch <walch.martin@web.de> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: "Yann E. MORIN: <yann.morin.1998@free.fr>
2012-11-20kconfig: Fix malloc handling in conf toolsAlan Cox1-4/+4
(and get them out of the noise in the audit work) Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2011-07-30Merge branch 'kconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6Linus Torvalds1-1/+0
* 'kconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6: (25 commits) kconfig: Introduce IS_ENABLED(), IS_BUILTIN() and IS_MODULE() xconfig: Abort close if configuration cannot be saved kconfig: fix missing "0x" prefix from S_HEX symbol in autoconf.h kconfig/nconf: remove useless conditionnal kconfig/nconf: prevent segfault on empty menu kconfig/nconf: use the generic menu_get_ext_help() nconfig: Avoid Wunused-but-set warning kconfig/conf: mark xfgets() private kconfig: remove pending prototypes for kconfig_load() kconfig/conf: add command line options' description kconfig/conf: reduce the scope of `defconfig_file' kconfig: use calloc() for expr allocation kconfig: introduce specialized printer kconfig: do not overwrite symbol direct dependency in assignment kconfig/gconf: silent missing prototype warnings kconfig/gconf: kill deadcode kconfig: nuke LKC_DIRECT_LINK cruft kconfig: nuke reference to SWIG kconfig: add missing <stdlib.h> inclusion kconfig: add missing <ctype.h> inclusion ... Fix up conflicts in scripts/kconfig/Makefile
2011-06-09kconfig/zconf.l: do not ask to generate backupArnaud Lacombe1-2/+2
This avoids the creation of a top-level `lex.backup' when the lexer gets re-generated. Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
2011-06-09kconfig: constify `kconf_id_lookup'Arnaud Lacombe1-2/+2
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
2011-06-06kconfig: nuke LKC_DIRECT_LINK cruftArnaud Lacombe1-1/+0
This interface is not (and has never been ?) used by any frontend, just get rid of it. Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
2011-04-15kconfig: get rid of unused flagsYann E. MORIN1-4/+0
Now that we detect recusrion of sourced files, get rid of now unused flags. Regenerate lex.zconf.c_shipped file. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> Signed-off-by: Michal Marek <mmarek@suse.cz>
2011-04-15kconfig: allow multiple inclusion of the same fileYann E. MORIN1-10/+19
Allow 'source'ing the same file from multiple places (eg. from different files, and/or under different conditions). To avoid circular inclusion, scan the source-ancestry of the current file, and abort if already sourced in this branch. Regenerate the pre-parsed lex.zconf.c_shipped file. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-09-19kconfig: use the file's name of sourced fileArnaud Lacombe1-2/+3
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Michal Marek <mmarek@suse.cz>
2010-09-19kconfig: constify file nameArnaud Lacombe1-1/+1
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Michal Marek <mmarek@suse.cz>
2009-11-15kconfig: Mark various internal functions staticJosh Triplett1-3/+3
kconfig's keyword hash, lexer, and parser define various functions used only locally. Declare these functions as static, and regenerate the corresponding generated files. Signed-off-by: Josh Triplett <josh@joshtriplett.org>
2009-01-02kconfig: improve error messages for bad source statementsSam Ravnborg1-2/+5
We now say where we detect the second source of a file, and where we detect a recursively source of the same file. This makes it easier to fix such errors. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Roman Zippel <zippel@linux-m68k.org>
2008-07-30kconfig: scripts/kconfig/zconf.l: add %option noinputAdrian Bunk1-0/+1
gcc 4.3 correctly determines that input() is unused and gives the following warning: <-- snip --> ... HOSTCC scripts/kconfig/zconf.tab.o scripts/kconfig/lex.zconf.c:1628: warning: ‘input’ defined but not used ... <-- snip --> Fix it by adding %option noinput to scripts/kconfig/zconf.l and regeneration of scripts/kconfig/lex.zconf.c_shipped. Signed-off-by: Adrian Bunk <bunk@kernel.org> Cc: Roman Zippel <zippel@linux-m68k.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2008-01-28kconfig: whitespace removingEGRY Gabor1-0/+5
This patch removes the unnecessary whitespaces from end of help lines of Kconfig files. Signed-off-by: Egry Gabor <gaboregry1@t-online.hu> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Roman Zippel <zippel@linux-m68k.org>
2007-05-06kconfig: fix mconf segmentation faultMarcin Garski1-1/+1
I have found small bug in mconf, when you run it without any argument it will sigsegv. Without patch: $ scripts/kconfig/mconf Segmentation fault With patch: $ scripts/kconfig/mconf can't find file (null) Signed-off-by: Marcin Garski <mgarski@post.pl> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>