Skip to content

L
linux
Commit 249502cc authored by Roman Zippel's avatar Roman Zippel Committed by Linus Torvalds
Browse files
Options

[PATCH] kconfig documentation update 

This removes the old documentation, adds the new one and fixes all
references to it.
parent dfeaca8c
Show whitespace changes
Inline Side-by-side
Showing with 274 additions and 729 deletions
Documentation/DocBook/kernel-hacking.tmpl
View file @ 249502cc
......@@ -1247,7 +1247,7 @@ static struct block_device_operations opt_fops = {
bash, even though it looks like bash; the safe way is to use only
the constructs that you already see in
<filename>Config.in</filename> files (see
<filename>Documentation/kbuild/config-language.txt</filename>).
<filename>Documentation/kbuild/kconfig-language.txt</filename>).
It's good to run "make xconfig" at least once to test (because
it's the only one with a static parser).
</para>
......
Documentation/kbuild/00-INDEX
View file @ 249502cc
......@@ -4,7 +4,7 @@ bug-list.txt
- known bugs in kbuild programs
commands.txt
- overview of kbuild commands
config-language.txt
- specification of Config Language, the language in Config.in files
kconfig-language.txt
- specification of Config Language, the language in Kconfig files
makefiles.txt
- developer information for linux kernel makefiles
Documentation/kbuild/config-language.txt deleted 100644 → 0
View file @ dfeaca8c
Config Language Specification
18 October 1999
Michael Elizabeth Chastain, <mailto:mec@shout.net>
=== Introduction
Config Language is not 'bash'.
This document describes Config Language, the Linux Kernel Configuration
Language. config.in and Config.in files are written in this language.
Although it looks, and usually acts, like a subset of the 'sh' language,
Config Language has a restricted syntax and different semantics.
Here is a basic guideline for Config Language programming: use only the
programming idioms that you see in existing Config.in files. People often
draw on their shell programming experience to invent idioms that look
reasonable to shell programmers, but silently fail in Config Language.
Config Language is not 'bash'.
=== Interpreters
Four different configuration programs read Config Language:
scripts/Configure make config, make oldconfig
scripts/Menuconfig make menuconfig
scripts/tkparse make xconfig
mconfig ftp.kernel.org/pub/linux/kernel/people/hch/mconfig/
'Configure' is a bash script which interprets Config.in files by sourcing
them. Some of the Config Language commands are native bash commands;
simple bash functions implement the rest of the commands.
'Menuconfig' is another bash script. It scans the input files with a
small awk script, builds a shell function for each menu, sources the
shell functions that it builds, and then executes the shell functions
in a user-driven order. Menuconfig uses 'lxdialog', a back-end utility
program, to perform actual screen output. 'lxdialog' is a C program
which uses curses.
'scripts/tkparse' is a C program with an ad hoc parser which translates
a Config Language script to a huge TCL/TK program. 'make xconfig'
then hands this TCL/TK program to 'wish', which executes it.
'mconfig' is the next generation of Config Language interpreters. It is a
C program with a bison parser which translates a Config Language script
into an internal syntax tree and then hands the syntax tree to one of
several user-interface front ends.
=== Statements
A Config Language script is a list of statements. There are 21 simple
statements; an 'if' statement; menu blocks; and a 'source' statement.
A '\' at the end of a line marks a line continuation.
'#' usually introduces a comment, which continues to the end of the line.
Lines of the form '# ... is not set', however, are not comments. They
are semantically meaningful, and all four config interpreters implement
this meaning.
Newlines are significant. You may not substitute semicolons for newlines.
The 'if' statement does accept a semicolon in one position; you may use
a newline in that position instead.
Here are the basic grammar elements.
A /prompt/ is a single-quoted string or a double-quoted string.
If the word is double-quoted, it may not have any $ substitutions.
A /word/ is a single unquoted word, a single-quoted string, or a
double-quoted string. If the word is unquoted or double quoted,
then $-substitution will be performed on the word.
A /symbol/ is a single unquoted word. A symbol must have a name of
the form CONFIG_*. scripts/mkdep.c relies on this convention in order
to generate dependencies on individual CONFIG_* symbols instead of
making one massive dependency on include/linux/autoconf.h.
A /dep/ is a dependency. Syntactically, it is a /word/. At run
time, a /dep/ must evaluate to "y", "m", "n", or "".
An /expr/ is a bash-like expression using the operators
'=', '!=', '-a', '-o', and '!'.
Here are all the statements:
Text statements:
mainmenu_name /prompt/
comment /prompt/
text /prompt/
Ask statements:
bool /prompt/ /symbol/
hex /prompt/ /symbol/ /word/
int /prompt/ /symbol/ /word/
string /prompt/ /symbol/ /word/
tristate /prompt/ /symbol/
Define statements:
define_bool /symbol/ /word/
define_hex /symbol/ /word/
define_int /symbol/ /word/
define_string /symbol/ /word/
define_tristate /symbol/ /word/
Dependent statements:
dep_bool /prompt/ /symbol/ /dep/ ...
dep_mbool /prompt/ /symbol/ /dep/ ...
dep_hex /prompt/ /symbol/ /word/ /dep/ ...
dep_int /prompt/ /symbol/ /word/ /dep/ ...
dep_string /prompt/ /symbol/ /word/ /dep/ ...
dep_tristate /prompt/ /symbol/ /dep/ ...
Unset statement:
unset /symbol/ ...
Choice statements:
choice /prompt/ /word/ /word/
nchoice /prompt/ /symbol/ /prompt/ /symbol/ ...
If statements:
if [ /expr/ ] ; then
/statement/
...
fi
if [ /expr/ ] ; then
/statement/
...
else
/statement/
...
fi
Menu block:
mainmenu_option next_comment
comment /prompt/
/statement/
...
endmenu
Source statement:
source /word/
=== mainmenu_name /prompt/
This verb is a lot less important than it looks. It specifies the top-level
name of this Config Language file.
Configure: ignores this line
Menuconfig: ignores this line
Xconfig: uses /prompt/ for the label window.
mconfig: ignores this line (mconfig does a better job without it).
Example:
# arch/sparc/config.in
mainmenu_name "Linux/SPARC Kernel Configuration"
=== comment /prompt/
This verb displays its prompt to the user during the configuration process
and also echoes it to the output files during output. Note that the
prompt, like all prompts, is a quoted string with no dollar substitution.
The 'comment' verb is not a Config Language comment. It causes the
user interface to display text, and it causes output to appear in the
output files.
Configure: implemented
Menuconfig: implemented
Xconfig: implemented
mconfig: implemented
Example:
# drivers/net/Config.in
comment 'CCP compressors for PPP are only built as modules.'
=== text /prompt/
This verb displays the prompt to the user with no adornment whatsoever.
It does not echo the prompt to the output file. mconfig uses this verb
internally for its help facility.
Configure: not implemented
Menuconfig: not implemented
Xconfig: not implemented
mconfig: implemented
Example:
# mconfig internal help text
text 'Here are all the mconfig command line options.'
=== bool /prompt/ /symbol/
This verb displays /prompt/ to the user, accepts a value from the user,
and assigns that value to /symbol/. The legal input values are "n" and
"y".
Note that the bool verb does not have a default value. People keep
trying to write Config Language scripts with a default value for bool,
but *all* of the existing language interpreters discard additional values.
Feel free to submit a multi-interpreter patch to linux-kbuild if you
want to implement this as an enhancement.
Configure: implemented
Menuconfig: implemented
Xconfig: implemented
mconfig: implemented
Example:
# arch/i386/config.in
bool 'Symmetric multi-processing support' CONFIG_SMP
=== hex /prompt/ /symbol/ /word/
This verb displays /prompt/ to the user, accepts a value from the user,
and assigns that value to /symbol/. Any hexadecimal number is a legal
input value. /word/ is the default value.
The hex verb does not accept range parameters.
Configure: implemented
Menuconfig: implemented
Xconfig: implemented
mconfig: implemented
Example:
# drivers/sound/Config.in
hex 'I/O base for SB Check from manual of the card' CONFIG_SB_BASE 220
=== int /prompt/ /symbol/ /word/
This verb displays /prompt/ to the user, accepts a value from the user,
and assigns that value to /symbol/. /word/ is the default value.
Any decimal number is a legal input value.
The int verb does not accept range parameters.
Configure: implemented
Menuconfig: implemented
Xconfig: implemented
mconfig: implemented
Example:
# drivers/char/Config.in
int 'Maximum number of Unix98 PTYs in use (0-2048)' \
CONFIG_UNIX98_PTY_COUNT 256
=== string /prompt/ /symbol/ /word/
This verb displays /prompt/ to the user, accepts a value from the user,
and assigns that value to /symbol/. /word/ is the default value. Legal
input values are any ASCII string, except for the characters '"' and '\\'.
Configure will trap an input string of "?" to display help.
The default value is mandatory.
Configure: implemented
Menuconfig: implemented
Xconfig: implemented
mconfig: implemented
Example:
# drivers/sound/Config.in
string ' Full pathname of DSPxxx.LD firmware file' \
CONFIG_PSS_BOOT_FILE /etc/sound/dsp001.ld
=== tristate /prompt/ /symbol/
This verb displays /prompt/ to the user, accepts a value from the user,
and assigns that value to /symbol/. Legal values are "n", "m", or "y".
The value "m" stands for "module"; it indicates that /symbol/ should
be built as a kernel module. The value "m" is legal only if the symbol
CONFIG_MODULES currently has the value "y".
The tristate verb does not have a default value.
Configure: implemented
Menuconfig: implemented
Xconfig: implemented
mconfig: implemented
Example:
# fs/Config.in
tristate 'NFS filesystem support' CONFIG_NFS_FS
=== define_bool /symbol/ /word/
This verb the value of /word/ to /symbol/. Legal values are "n" or "y".
For compatibility reasons, the value of "m" is also legal, because it
will be a while before define_tristate is implemented everywhere.
Configure: implemented
Menuconfig: implemented
Xconfig: implemented
mconfig: implemented
Example:
# arch/alpha/config.in
if [ "$CONFIG_ALPHA_GENERIC" = "y" ]
then
define_bool CONFIG_PCI y
define_bool CONFIG_ALPHA_NEED_ROUNDING_EMULATION y
fi
=== define_hex /symbol/ /word/
This verb assigns the value of /word/ to /symbol/. Any hexadecimal
number is a legal value.
Configure: implemented
Menuconfig: implemented
Xconfig: implemented
mconfig: implemented
Example:
# Not from the corpus
bool 'Specify custom serial port' CONFIG_SERIAL_PORT_CUSTOM
if [ "$CONFIG_SERIAL_PORT_CUSTOM" = "y" ]; then
hex 'Serial port number' CONFIG_SERIAL_PORT
else
define_hex CONFIG_SERIAL_PORT 0x3F8
fi
=== define_int /symbol/ /word/
This verb assigns /symbol/ the value /word/. Any decimal number is a
legal value.
Configure: implemented
Menuconfig: implemented
Xconfig: implemented
mconfig: implemented
Example:
# drivers/char/ftape/Config.in
define_int CONFIG_FT_ALPHA_CLOCK 0
=== define_string /symbol/ /word/
This verb assigns the value of /word/ to /symbol/. Legal input values
are any ASCII string, except for the characters '"' and '\\'.
Configure: implemented
Menuconfig: implemented
Xconfig: implemented
mconfig: implemented
Example
# Not from the corpus
define_string CONFIG_VERSION "2.2.0"
=== define_tristate /symbol/ /word/
This verb assigns the value of /word/ to /symbol/. Legal input values
are "n", "m", and "y".
As soon as this verb is implemented in all interpreters, please use it
instead of define_bool to define tristate values. This aids in static
type checking.
Configure: implemented
Menuconfig: implemented
Xconfig: implemented
mconfig: implemented
Example:
# drivers/video/Config.in
if [ "$CONFIG_FB_AMIGA" = "y" ]; then
define_tristate CONFIG_FBCON_AFB y
define_tristate CONFIG_FBCON_ILBM y
else
if [ "$CONFIG_FB_AMIGA" = "m" ]; then
define_tristate CONFIG_FBCON_AFB m
define_tristate CONFIG_FBCON_ILBM m
fi
fi
=== dep_bool /prompt/ /symbol/ /dep/ ...
This verb evaluates all of the dependencies in the dependency list.
Any dependency which has a value of "y" does not restrict the input
range. Any dependency which has an empty value is ignored.
Any dependency which has a value of "n", or which has some other value,
(like "m") restricts the input range to "n". Quoting dependencies is not
allowed. Using dependencies with an empty value possible is not
recommended. See also dep_mbool below.
If the input range is restricted to the single choice "n", dep_bool
silently assigns "n" to /symbol/. If the input range has more than
one choice, dep_bool displays /prompt/ to the user, accepts a value
from the user, and assigns that value to /symbol/.
Configure: implemented
Menuconfig: implemented
XConfig: implemented
mconfig: implemented
Example:
# drivers/net/Config.in
dep_bool 'Aironet 4500/4800 PCI support 'CONFIG_AIRONET4500_PCI $CONFIG_PCI
Known bugs:
- Xconfig does not write "# foo is not set" to .config (as well as
"#undef foo" to autoconf.h) if command is disabled by its dependencies.
=== dep_mbool /prompt/ /symbol/ /dep/ ...
This verb evaluates all of the dependencies in the dependency list.
Any dependency which has a value of "y" or "m" does not restrict the
input range. Any dependency which has an empty value is ignored.
Any dependency which has a value of "n", or which has some other value,
restricts the input range to "n". Quoting dependencies is not allowed.
Using dependencies with an empty value possible is not recommended.
If the input range is restricted to the single choice "n", dep_bool
silently assigns "n" to /symbol/. If the input range has more than
one choice, dep_bool displays /prompt/ to the user, accepts a value
from the user, and assigns that value to /symbol/.
Notice that the only difference between dep_bool and dep_mbool
is in the way of treating the "m" value as a dependency.
Configure: implemented
Menuconfig: implemented
XConfig: implemented
mconfig: implemented
Example:
# Not from the corpus
dep_mbool 'Packet socket: mmapped IO' CONFIG_PACKET_MMAP $CONFIG_PACKET
Known bugs:
- Xconfig does not write "# foo is not set" to .config (as well as
"#undef foo" to autoconf.h) if command is disabled by its dependencies.
=== dep_hex /prompt/ /symbol/ /word/ /dep/ ...
=== dep_int /prompt/ /symbol/ /word/ /dep/ ...
=== dep_string /prompt/ /symbol/ /word/ /dep/ ...
I am still thinking about the semantics of these verbs.
Configure: not implemented
Menuconfig: not implemented
XConfig: not implemented
mconfig: not implemented
=== dep_tristate /prompt/ /symbol/ /dep/ ...
This verb evaluates all of the dependencies in the dependency list.
Any dependency which has a value of "y" does not restrict the input range.
Any dependency which has a value of "m" restricts the input range to
"m" or "n". Any dependency which has an empty value is ignored.
Any dependency which has a value of "n", or which has some other value,
restricts the input range to "n". Quoting dependencies is not allowed.
Using dependencies with an empty value possible is not recommended.
If the input range is restricted to the single choice "n", dep_tristate
silently assigns "n" to /symbol/. If the input range has more than
one choice, dep_tristate displays /prompt/ to the user, accepts a value
from the user, and assigns that value to /symbol/.
Configure: implemented
Menuconfig: implemented
Xconfig: implemented
mconfig: implemented
Example:
# drivers/char/Config.in
dep_tristate 'Parallel printer support' CONFIG_PRINTER $CONFIG_PARPORT
Known bugs:
- Xconfig does not write "# foo is not set" to .config (as well as
"#undef foo" to autoconf.h) if command is disabled by its dependencies.
=== unset /symbol/ ...
This verb assigns the value "" to /symbol/, but does not cause /symbol/
to appear in the output. The existence of this verb is a hack; it covers
up deeper problems with variable semantics in a random-execution language.
Configure: implemented
Menuconfig: implemented
Xconfig: implemented (with bugs)
mconfig: implemented
Example:
# arch/mips/config.in
unset CONFIG_PCI
unset CONFIG_MIPS_JAZZ
unset CONFIG_VIDEO_G364
=== choice /prompt/ /word/ /word/
This verb implements a choice list or "radio button list" selection.
It displays /prompt/ to the user, as well as a group of sub-prompts
which have corresponding symbols.
When the user selects a value, the choice verb sets the corresponding
symbol to "y" and sets all the other symbols in the choice list to "n".
The second argument is a single-quoted or double-quoted word that
describes a series of sub-prompts and symbol names. The interpreter
breaks up the word at white space boundaries into a list of sub-words.
The first sub-word is the first prompt; the second sub-word is the
first symbol. The third sub-word is the second prompt; the fourth
sub-word is the second symbol. And so on, for all the sub-words.
The third word is a literal word. Its value must be a unique abbreviation
for exactly one of the prompts. The symbol corresponding to this prompt
is the default enabled symbol.
Note that because of the syntax of the choice verb, the sub-prompts
may not have spaces in them.
Configure: implemented
Menuconfig: implemented
Xconfig: implemented
mconfig: implemented
Example:
# arch/i386/config.in
choice ' PCI access mode' \
"BIOS CONFIG_PCI_GOBIOS \
Direct CONFIG_PCI_GODIRECT \
Any CONFIG_PCI_GOANY" Any
=== nchoice /prompt/ /symbol/ /prompt/ /symbol/ ...
This verb has the same semantics as the choice verb, but with a sensible
syntax.
The first /prompt/ is the master prompt for the entire choice list.
The first /symbol/ is the default symbol to enable (notice that this
is a symbol, not a unique prompt abbreviation).
The subsequent /prompt/ and /symbol/ pairs are the prompts and symbols
for the choice list.
Configure: not implemented
Menuconfig: not implemented
XConfig: not implemented
mconfig: implemented
=== if [ /expr/ ] ; then
This is a conditional statement, with an optional 'else' clause. You may
substitute a newline for the semicolon if you choose.
/expr/ may contain the following atoms and operators. Note that, unlike
shell, you must use double quotes around every atom.
/atom/:
"..." a literal
"$..." a variable
/expr/:
/atom/ = /atom/ true if atoms have identical value
/atom/ != /atom/ true if atoms have different value
/expr/:
/expr/ -o /expr/ true if either expression is true
/expr/ -a /expr/ true if both expressions are true
! /expr/ true if expression is not true
Note that a naked /atom/ is not a valid /expr/. If you try to use it
as such:
# Do not do this.
if [ "$CONFIG_EXPERIMENTAL" ]; then
bool 'Bogus experimental feature' CONFIG_BOGUS
fi
... then you will be surprised, because CONFIG_EXPERIMENTAL never has a
value of the empty string! It is always "y" or "n", and both of these
are treated as true (non-empty) by the bash-based interpreters Configure
and Menuconfig.
Configure: implemented
Menuconfig: implemented
XConfig: implemented, with bugs
mconfig: implemented
Xconfig has some known bugs, and probably some unknown bugs too:
- literals with an empty "" value are not properly handled.
=== mainmenu_option next_comment
This verb introduces a new menu. The next statement must have a comment
verb. The /prompt/ of that comment verb becomes the title of the menu.
(I have no idea why the original designer didn't create a 'menu ...' verb).
Statements outside the scope of any menu are in the implicit top menu.
The title of the top menu comes from a variety of sources, depending on
the interpreter.
Configure: implemented
Menuconfig: implemented
Xconfig: implemented
mconfig: implemented
=== endmenu
This verb closes the scope of a menu.
Configure: implemented
Menuconfig: implemented
Xconfig: implemented
mconfig: implemented
=== source /word/
This verb interprets the literal /word/ as a filename, and interpolates
the contents of that file. The word must be a single unquoted literal
word.
Some interpreters interpret this verb at run time; some interpreters
interpret it at parse time.
Inclusion is textual inclusion, like the C preprocessor #include facility.
The source verb does not imply a submenu or any kind of block nesting.
Configure: implemented (run time)
Menuconfig: implemented (parse time)
Xconfig: implemented (parse time)
mconfig: implemented (parse time)
Documentation/kbuild/kconfig-language.txt 0 → 100644
View file @ 249502cc
Introduction
------------
The configuration database is collection of configuration options
organized in a tree structure:
+- Code maturity level options
| +- Prompt for development and/or incomplete code/drivers
+- General setup
| +- Networking support
| +- System V IPC
| +- BSD Process Accounting
| +- Sysctl support
+- Loadable module support
| +- Enable loadable module support
| +- Set version information on all module symbols
| +- Kernel module loader
+- ...
Every entry has its own dependencies. These dependencies are used
to determine the visible of an entry. Any child entry is only
visible if its parent entry is also visible.
Menu entries
------------
Most entries define a config option, all other entries help to organize
them. A single configuration option is defined like this:
config MODVERSIONS
bool "Set version information on all module symbols"
depends MODULES
help
Usually, modules have to be recompiled whenever you switch to a new
kernel. ...
Every line starts with a key word and can be followed by multiple
arguments. "config" starts a new config entry. The following lines
define attributes for this config option. Attributes can be the type of
the config option, input prompt, dependencies, help text and default
values. A config option can be defined multiple times with the same
name, but every definition can have only a single input prompt and the
type must not conflict.
Menu attributes
---------------
A menu entry can have a number of attributes. Not all of them are
applicable everywhere (see syntax).
- type definition: "bool"/"tristate"/"string"/"hex"/"integer"
Every config option must have a type. There are only two basic types:
tristate and string, the other types base on these two. The type
definition optionally accepts an input prompt, so these two examples
are equivalent:
bool "Networking support"
and
bool
prompt "Networking support"
- input prompt: "prompt" <prompt> ["if" <expr>]
Every menu entry can have at most one prompt, which is used to display
to the user. Optionally dependencies only for this prompt can be added
with "if".
- default value: "default" <symbol> ["if" <expr>]
A config option can have any number of default values. If multiple
default values are visible, only the first defined one is active.
Default values are not limited to the menu entry, where they are
defined, this means the default can be defined somewhere else or be
overriden by an earlier definition.
The default value is only assigned to the config symbol if no other
value was set by the user (via the input prompt above). If an input
prompt is visible the default value is presented to the user and can
be overridden by him.
Optionally dependencies only for this default value can be added with
"if".
- dependencies: "depends on"/"requires" <expr>
This defines a dependency for this menu entry. If multiple
dependencies are defined they are connected with '&&'. Dependencies
are applied to all other options within this menu entry (which also
accept "if" expression), so these two examples are equivalent:
bool "foo" if BAR
default y if BAR
and
depends on BAR
bool "foo"
default y
- help text: "help"
This defines a help text. The end of the help text is determined by
the level indentation, this means it ends at the first line which has
a smaller indentation than the first line of the help text.
Menu dependencies
-----------------
Dependencies define the visibility of a menu entry and can also reduce
the input range of tristate symbols. The tristate logic used in the
expressions uses one more state than normal boolean logic to express the
module state. Dependency expressions have the following syntax:
<expr> ::= <symbol> (1)
<symbol> '=' <symbol> (2)
<symbol> '!=' <symbol> (3)
'(' <expr> ')' (4)
'!' <expr> (5)
<expr> '||' <expr> (6)
<expr> '&&' <expr> (7)
Expressions are listed in decreasing order of precedence.
(1) Convert the symbol into an expression. Boolean and tristate symbols
are simply converted into the respective expression values. All
other symbol types result in 'n'.
(2) If the values of both symbols are equal, it returns 'y',
otherwise 'n'.
(3) If the values of both symbols are equal, it returns 'n',
otherwise 'y'.
(4) Returns the value of the expression. Used to override precedence.
(5) Returns the result of (2-/expr/).
(6) Returns the result of min(/expr/, /expr/).
(7) Returns the result of max(/expr/, /expr/).
An expression can have a value of 'n', 'm' or 'y' (or 0, 1, 2
respectively for calculations). A menu entry becomes visible when it's
expression evaluates to 'm' or 'y'.
There are two type of symbols: constant and nonconstant symbols.
Nonconstant symbols are the most common ones and are defined with the
'config' statement. Nonconstant symbols consist entirely of alphanumeric
characters or underscores.
Constant symbols are only part of expressions. Constant symbols are
always surrounded by single or double quotes. Within the quote any
other character is allowed and the quotes can be escaped using '\'.
Menu structure
--------------
The position of a menu entry in the tree is determined in two ways. First
it can be specified explicitely:
menu "Network device support"
depends NET
config NETDEVICES
...
endmenu
All entries within the "menu" ... "endmenu" block become a submenu of
"Network device support". All subentries inherit the dependencies from
the menu entry, e.g. this means the dependency "NET" is added to the
dependency list of the config option NETDEVICES.
The other way to generate the menu structure is done by analyzing the
dependencies. If a menu entry somehow depends on the previous entry, it
can be made a submenu of it. First the the previous (parent) symbol must
be part of the dependency list and then one of these two condititions
must be true:
- the child entry must become invisible, if the parent is set to 'n'
- the child entry must only be visible, if the parent is visible
config MODULES
bool "Enable loadable module support"
config MODVERSIONS
bool "Set version information on all module symbols"
depends MODULES
comment "module support disabled"
depends !MODULES
MODVERSIONS directly depends on MODULES, this means it's only visible if
MODULES is different from 'n'. The comment on the other hand is always
visible when MODULES it's visible (the (empty) dependency of MODULES is
also part of the comment dependencies).
Kconfig syntax
--------------
The configuration file describes a series of menu entries, where every
line starts with a keyword (except help texts). The following keywords
end a menu entry:
- config
- choice/endchoice
- comment
- menu/endmenu
- if/endif
- source
The first four also start the definition of a menu entry.
config:
"config" <symbol>
<config options>
This defines a config symbol <symbol> and accepts any of above
attributes as options.
choices:
"choice"
<choice options>
<choice block>
"endchoice"
This defines a choice group and accepts any of above attributes as
options. A choice can only be of type bool or tristate, while a boolean
choice only allows a single config entry to be selected, a tristate
choice also allows any number of config entries to be set to 'm'. This
can be used if multiple drivers for a single hardware exists and only a
single driver can be compiled/loaded into the kernel, but all drivers
can be compiled as modules.
A choice accepts another option "optional", which allows to set the
choice to 'n' and no entry needs to be selected.
comment:
"comment" <prompt>
<comment options>
This defines a comment which is displayed to the user during the
configuration process and is also echoed to the output files. The only
possible options are dependencies.
menu:
"menu" <prompt>
<menu options>
<menu block>
"endmenu"
This defines a menu block, see "Menu structure" above for more
information. The only possible options are dependencies.
if:
"if" <expr>
<if block>
"endif"
This defines an if block. The dependency expression <expr> is appended
to all enclosed menu entries.
source:
"source" <prompt>
This reads the specified configuration file. This file is always parsed.
arch/alpha/Kconfig
View file @ 249502cc
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/config-language.txt.
# see Documentation/kbuild/kconfig-language.txt.
#
config ALPHA
bool
......
arch/arm/Kconfig
View file @ 249502cc
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/config-language.txt.
# see Documentation/kbuild/kconfig-language.txt.
#
mainmenu "Linux Kernel Configuration"
......
arch/i386/Kconfig
View file @ 249502cc
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/config-language.txt.
# see Documentation/kbuild/kconfig-language.txt.
#
mainmenu "Linux Kernel Configuration"
......
arch/m68k/Kconfig
View file @ 249502cc
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/config-language.txt.
# see Documentation/kbuild/kconfig-language.txt.
#
config M68K
bool
......
arch/m68knommu/Kconfig
View file @ 249502cc
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/config-language.txt.
# see Documentation/kbuild/kconfig-language.txt.
#
mainmenu "uClinux/68k (w/o MMU) Kernel Configuration"
......
arch/mips/Kconfig
View file @ 249502cc
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/config-language.txt.
# see Documentation/kbuild/kconfig-language.txt.
#
config MIPS
bool
......
arch/mips64/Kconfig
View file @ 249502cc
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/config-language.txt.
# see Documentation/kbuild/kconfig-language.txt.
#
mainmenu "Linux Kernel Configuration"
......
arch/ppc/Kconfig
View file @ 249502cc
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/config-language.txt.
# see Documentation/kbuild/kconfig-language.txt.
#
config MMU
......
arch/ppc64/Kconfig
View file @ 249502cc
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/config-language.txt.
# see Documentation/kbuild/kconfig-language.txt.
#
config MMU
......
arch/s390/Kconfig
View file @ 249502cc
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/config-language.txt.
# see Documentation/kbuild/kconfig-language.txt.
#
config MMU
......
arch/s390x/Kconfig
View file @ 249502cc
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/config-language.txt.
# see Documentation/kbuild/kconfig-language.txt.
#
config MMU
......
arch/sh/Kconfig
View file @ 249502cc
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/config-language.txt.
# see Documentation/kbuild/kconfig-language.txt.
#
mainmenu "Linux/SuperH Kernel Configuration"
......
arch/sparc/Kconfig
View file @ 249502cc
# $Id: config.in,v 1.113 2002/01/24 22:14:44 davem Exp $
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/config-language.txt.
# see Documentation/kbuild/kconfig-language.txt.
#
mainmenu "Linux/SPARC Kernel Configuration"
......
arch/v850/Kconfig
View file @ 249502cc
#############################################################################
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/config-language.txt.
# see Documentation/kbuild/kconfig-language.txt.
#
#############################################################################
......
arch/x86_64/Kconfig
View file @ 249502cc
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/config-language.txt.
# see Documentation/kbuild/kconfig-language.txt.
#
# Note: ISA is disabled and will hopefully never be enabled.
# If you managed to buy an ISA x86-64 box you'll have to fix all the
......
drivers/parport/Kconfig
View file @ 249502cc
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/config-language.txt.
# see Documentation/kbuild/kconfig-language.txt.
#
# Parport configuration.
#
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7