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
------------

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, but every definition can have only a single
input prompt and the type must not conflict.

Menu dependencies
-----------------

Dependencies define the visibility of a menu entry. When a dependency
exprecession evaluates not to 'n', the entry is visible. Additionally
the dependency limits the input range of tristate choice symbols.

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
"Processor type and features". All subentries have the same dependencies
than the menu entry, e.g. this means the dependency "NET" is added to the
dependencies of the 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.

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 dependency of MODULES are part
of the comment dependencies).

Menu attributes
---------------

A menu attribute can have a number of attributes. Not all of them are
applicable everywhere (see spec).
Input prompt: Every menu entry can have at most one menu entry, which
is used to display to the user. An input prompt is either defined with
"prompt" or it can be defined with the type.
Type definition: Every config option must have a type, known types are
currently: bool, tristate, string, hex, integer.
Default value: It's possible to assign a config option a default value.
This default is always used, when the option wasn't explicitly set by
the user. This means it's either used as default value for input prompts
or the value is saved to the kernel configuration. Multiple default
values can be specified and every one has it's own dependencies. If
multiple default values are visible, the first defined one is active.
A default is not limited to a single menu entry, this means the default
doesn't has to be defined with a input prompt, but it can also be
overridden by prepend it with another definition.
Dependencies: Dependencies can be either defined with "depends", then
there are applied to all attributes of a menu entry, or attribute
specific dependencies can be defined with "if", which immediately
follows the attribute.