|
@@ -1,7 +1,7 @@
|
|
|
Introduction
|
|
|
------------
|
|
|
|
|
|
-The configuration database is collection of configuration options
|
|
|
+The configuration database is a collection of configuration options
|
|
|
organized in a tree structure:
|
|
|
|
|
|
+- Code maturity level options
|
|
@@ -18,18 +18,18 @@ organized in a tree structure:
|
|
|
+- ...
|
|
|
|
|
|
Every entry has its own dependencies. These dependencies are used
|
|
|
-to determine the visible of an entry. Any child entry is only
|
|
|
+to determine the visibility 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
|
|
|
+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
|
|
|
+ depends on MODULES
|
|
|
help
|
|
|
Usually, modules have to be recompiled whenever you switch to a new
|
|
|
kernel. ...
|
|
@@ -48,9 +48,9 @@ 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"
|
|
|
+- type definition: "bool"/"tristate"/"string"/"hex"/"int"
|
|
|
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
|
|
|
+ tristate and string; the other types are based on these two. The type
|
|
|
definition optionally accepts an input prompt, so these two examples
|
|
|
are equivalent:
|
|
|
|
|
@@ -64,24 +64,29 @@ applicable everywhere (see syntax).
|
|
|
to the user. Optionally dependencies only for this prompt can be added
|
|
|
with "if".
|
|
|
|
|
|
-- default value: "default" <symbol> ["if" <expr>]
|
|
|
+- default value: "default" <expr> ["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.
|
|
|
+ Default values are not limited to the menu entry where they are
|
|
|
+ defined. This means the default can be defined somewhere else or be
|
|
|
+ overridden 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
|
|
|
+ Optionally, dependencies only for this default value can be added with
|
|
|
"if".
|
|
|
|
|
|
-- dependencies: "depends on"/"requires" <expr>
|
|
|
+- type definition + default value:
|
|
|
+ "def_bool"/"def_tristate" <expr> ["if" <expr>]
|
|
|
+ This is a shorthand notation for a type definition plus a value.
|
|
|
+ Optionally dependencies for this default value can be added with "if".
|
|
|
+
|
|
|
+- dependencies: "depends on" <expr>
|
|
|
This defines a dependency for this menu entry. If multiple
|
|
|
- dependencies are defined they are connected with '&&'. Dependencies
|
|
|
+ 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:
|
|
|
+ accept an "if" expression), so these two examples are equivalent:
|
|
|
|
|
|
bool "foo" if BAR
|
|
|
default y if BAR
|
|
@@ -90,11 +95,60 @@ applicable everywhere (see syntax).
|
|
|
bool "foo"
|
|
|
default y
|
|
|
|
|
|
-- help text: "help"
|
|
|
+- reverse dependencies: "select" <symbol> ["if" <expr>]
|
|
|
+ While normal dependencies reduce the upper limit of a symbol (see
|
|
|
+ below), reverse dependencies can be used to force a lower limit of
|
|
|
+ another symbol. The value of the current menu symbol is used as the
|
|
|
+ minimal value <symbol> can be set to. If <symbol> is selected multiple
|
|
|
+ times, the limit is set to the largest selection.
|
|
|
+ Reverse dependencies can only be used with boolean or tristate
|
|
|
+ symbols.
|
|
|
+ Note:
|
|
|
+ select should be used with care. select will force
|
|
|
+ a symbol to a value without visiting the dependencies.
|
|
|
+ By abusing select you are able to select a symbol FOO even
|
|
|
+ if FOO depends on BAR that is not set.
|
|
|
+ In general use select only for non-visible symbols
|
|
|
+ (no prompts anywhere) and for symbols with no dependencies.
|
|
|
+ That will limit the usefulness but on the other hand avoid
|
|
|
+ the illegal configurations all over.
|
|
|
+ kconfig should one day warn about such things.
|
|
|
+
|
|
|
+- numerical ranges: "range" <symbol> <symbol> ["if" <expr>]
|
|
|
+ This allows to limit the range of possible input values for int
|
|
|
+ and hex symbols. The user can only input a value which is larger than
|
|
|
+ or equal to the first symbol and smaller than or equal to the second
|
|
|
+ symbol.
|
|
|
+
|
|
|
+- help text: "help" or "---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
|
|
|
+ the indentation level, this means it ends at the first line which has
|
|
|
a smaller indentation than the first line of the help text.
|
|
|
-
|
|
|
+ "---help---" and "help" do not differ in behaviour, "---help---" is
|
|
|
+ used to help visually separate configuration logic from help within
|
|
|
+ the file as an aid to developers.
|
|
|
+
|
|
|
+- misc options: "option" <symbol>[=<value>]
|
|
|
+ Various less common options can be defined via this option syntax,
|
|
|
+ which can modify the behaviour of the menu entry and its config
|
|
|
+ symbol. These options are currently possible:
|
|
|
+
|
|
|
+ - "defconfig_list"
|
|
|
+ This declares a list of default entries which can be used when
|
|
|
+ looking for the default configuration (which is used when the main
|
|
|
+ .config doesn't exists yet.)
|
|
|
+
|
|
|
+ - "modules"
|
|
|
+ This declares the symbol to be used as the MODULES symbol, which
|
|
|
+ enables the third modular state for all config symbols.
|
|
|
+
|
|
|
+ - "env"=<value>
|
|
|
+ This imports the environment variable into Kconfig. It behaves like
|
|
|
+ a default, except that the value comes from the environment, this
|
|
|
+ also means that the behaviour when mixing it with normal defaults is
|
|
|
+ undefined at this point. The symbol is currently not exported back
|
|
|
+ to the build environment (if this is desired, it can be done via
|
|
|
+ another symbol).
|
|
|
|
|
|
Menu dependencies
|
|
|
-----------------
|
|
@@ -109,10 +163,10 @@ module state. Dependency expressions have the following syntax:
|
|
|
<symbol> '!=' <symbol> (3)
|
|
|
'(' <expr> ')' (4)
|
|
|
'!' <expr> (5)
|
|
|
- <expr> '||' <expr> (6)
|
|
|
- <expr> '&&' <expr> (7)
|
|
|
+ <expr> '&&' <expr> (6)
|
|
|
+ <expr> '||' <expr> (7)
|
|
|
|
|
|
-Expressions are listed in decreasing order of precedence.
|
|
|
+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
|
|
@@ -130,22 +184,22 @@ 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
|
|
|
+There are two types of symbols: constant and non-constant symbols.
|
|
|
+Non-constant symbols are the most common ones and are defined with the
|
|
|
+'config' statement. Non-constant 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
|
|
|
+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:
|
|
|
+it can be specified explicitly:
|
|
|
|
|
|
menu "Network device support"
|
|
|
- depends NET
|
|
|
+ depends on NET
|
|
|
|
|
|
config NETDEVICES
|
|
|
...
|
|
@@ -159,8 +213,8 @@ 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
|
|
|
+can be made a submenu of it. First, the previous (parent) symbol must
|
|
|
+be part of the dependency list and then one of these two conditions
|
|
|
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
|
|
@@ -170,14 +224,14 @@ config MODULES
|
|
|
|
|
|
config MODVERSIONS
|
|
|
bool "Set version information on all module symbols"
|
|
|
- depends MODULES
|
|
|
+ depends on MODULES
|
|
|
|
|
|
comment "module support disabled"
|
|
|
- depends !MODULES
|
|
|
+ depends on !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
|
|
|
+visible when MODULES is visible (the (empty) dependency of MODULES is
|
|
|
also part of the comment dependencies).
|
|
|
|
|
|
|
|
@@ -188,12 +242,13 @@ 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
|
|
|
+- menuconfig
|
|
|
- choice/endchoice
|
|
|
- comment
|
|
|
- menu/endmenu
|
|
|
- if/endif
|
|
|
- source
|
|
|
-The first four also start the definition of a menu entry.
|
|
|
+The first five also start the definition of a menu entry.
|
|
|
|
|
|
config:
|
|
|
|
|
@@ -203,6 +258,14 @@ config:
|
|
|
This defines a config symbol <symbol> and accepts any of above
|
|
|
attributes as options.
|
|
|
|
|
|
+menuconfig:
|
|
|
+ "menuconfig" <symbol>
|
|
|
+ <config options>
|
|
|
+
|
|
|
+This is similar to the simple config entry above, but it also gives a
|
|
|
+hint to front ends, that all suboptions should be displayed as a
|
|
|
+separate list of options.
|
|
|
+
|
|
|
choices:
|
|
|
|
|
|
"choice"
|
|
@@ -210,7 +273,7 @@ choices:
|
|
|
<choice block>
|
|
|
"endchoice"
|
|
|
|
|
|
-This defines a choice group and accepts any of above attributes as
|
|
|
+This defines a choice group and accepts any of the 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
|
|
@@ -253,3 +316,64 @@ source:
|
|
|
"source" <prompt>
|
|
|
|
|
|
This reads the specified configuration file. This file is always parsed.
|
|
|
+
|
|
|
+mainmenu:
|
|
|
+
|
|
|
+ "mainmenu" <prompt>
|
|
|
+
|
|
|
+This sets the config program's title bar if the config program chooses
|
|
|
+to use it.
|
|
|
+
|
|
|
+
|
|
|
+Kconfig hints
|
|
|
+-------------
|
|
|
+This is a collection of Kconfig tips, most of which aren't obvious at
|
|
|
+first glance and most of which have become idioms in several Kconfig
|
|
|
+files.
|
|
|
+
|
|
|
+Adding common features and make the usage configurable
|
|
|
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
+It is a common idiom to implement a feature/functionality that are
|
|
|
+relevant for some architectures but not all.
|
|
|
+The recommended way to do so is to use a config variable named HAVE_*
|
|
|
+that is defined in a common Kconfig file and selected by the relevant
|
|
|
+architectures.
|
|
|
+An example is the generic IOMAP functionality.
|
|
|
+
|
|
|
+We would in lib/Kconfig see:
|
|
|
+
|
|
|
+# Generic IOMAP is used to ...
|
|
|
+config HAVE_GENERIC_IOMAP
|
|
|
+
|
|
|
+config GENERIC_IOMAP
|
|
|
+ depends on HAVE_GENERIC_IOMAP && FOO
|
|
|
+
|
|
|
+And in lib/Makefile we would see:
|
|
|
+obj-$(CONFIG_GENERIC_IOMAP) += iomap.o
|
|
|
+
|
|
|
+For each architecture using the generic IOMAP functionality we would see:
|
|
|
+
|
|
|
+config X86
|
|
|
+ select ...
|
|
|
+ select HAVE_GENERIC_IOMAP
|
|
|
+ select ...
|
|
|
+
|
|
|
+Note: we use the existing config option and avoid creating a new
|
|
|
+config variable to select HAVE_GENERIC_IOMAP.
|
|
|
+
|
|
|
+Note: the use of the internal config variable HAVE_GENERIC_IOMAP, it is
|
|
|
+introduced to overcome the limitation of select which will force a
|
|
|
+config option to 'y' no matter the dependencies.
|
|
|
+The dependencies are moved to the symbol GENERIC_IOMAP and we avoid the
|
|
|
+situation where select forces a symbol equals to 'y'.
|
|
|
+
|
|
|
+Build as module only
|
|
|
+~~~~~~~~~~~~~~~~~~~~
|
|
|
+To restrict a component build to module-only, qualify its config symbol
|
|
|
+with "depends on m". E.g.:
|
|
|
+
|
|
|
+config FOO
|
|
|
+ depends on BAR && m
|
|
|
+
|
|
|
+limits FOO to module (=m) or disabled (=n).
|
|
|
+
|