KernelConf, a Linux kernel configuration system

By Anuradha Ratnaweera

Update: Kernelconf is not an actively developed software. It was only a proposed alternative to ESR's CML2. Here are Andrew Morton's comments about kernelconf.

Last updated on 9th February, 2002.

Latest snapshot of kernelconf is 0.1.3 (2002-02-09). See download section for more details.

• Why kernelconf?
• Introduction
• An example
• Config file format
  • Overview
  • Including other config files
  • Standalone tags
  • Symbols
  • Types
  • Setting values
  • Dependencies
  • Rules
  • Derived
  • Expressions
• Download

I was studying the available kernel configuration systems (CML1 and CML2) and for some reason didn't feel satisfied. CML1 lacks many features, while CML2 was a bit bulky and not very readable (to me, at least ;-().

Posting such issues on mailing lists didn't look very fruitful. On many occassions people ask `If you don't like it, why don't you develope your own way of doing it?'.

So, I started writing KernelConf.

I was mostly inspired by the package lists used by APT, the Debian package management tool. Simple, readable, yet powerful enough for the job at hand.

Advantages:

• Subsets of configuration options, help texts, menu items and dependencies is are kept in a seperate files scattered around the kernel tree, and is usually `owned' by a maintainer. This is supposed to ease maintainance as stated by Linus in one of the recent threads on LKML related to CML2 and kernel 2.5 build system.
• No global files are involved.
• Generates accurate configuration files.
• Supports features not available on CML1, such as using symbols in dependency expressions before declaring them.
• Doesn't require any tool or library in addition to what is required by CML1; C compiler for ttyconfig, curses for menuconfig and tck/tk for xconfig.

I haven't defined the formal grammer yet. Everything will be explained in terms of examples until things get stabilized.

Kernelconf contains

• A set of files that define configuration symbols, their dependencies, and a menu system to read in these symbols.
• A set of tools to display menus and obtain user input. `make config' and friends are handled by them.

In kernelconf, user is confronted with a menu hiearachy starting from the root menu-item `Linux kernel 2.x.x configuration'. All menu-items are treated equally, i.e., no special treatment is done for leaf nodes.

If a menu item is associated with a configuration symbol, turning it on (almost always setting it to `y' or `m') will set the value of the corresponding configuration symbol (e.g. CONFIG_SOUND and `Sound' menu).

However, unlike current tools, a sub menu can be viewed WITHOUT turning it on (not in ttyconfig, though).

Initially, kernelconf menu hierachy will be the same as the one in CML1, and changes will be introduced slowly to make it better structured. By doing so, end users will not feel annoyed during the migration.

Here is an example configuration file:

#
# Sound configuration file
# drivers/sound/sound.conf
#

symbol: SOUND
# depends:
# derived:
type: tristate
menu-caption: Sound card support
# menu-depends:
# menu-parent: is not required because this is in the root menu, (yet  ;))
description:
  If you have a sound card in your computer, i.e. if it can say more
  than an occasional beep, say Y.  Be sure to have all the information
  about your sound card and its configuration down (I/O port,
  interrupt and DMA channel), because you will be asked for it.

  You want to read the Sound-HOWTO, available from
  <http://www.linuxdoc.org/docs.html#howto>. General information about
  the modular sound system is contained in the files
  <file:Documentation/sound/Introduction>.  The file
  <file:Documentation/sound/README.OSS> contains some slightly
  outdated but still useful information as well.

  If you have a PnP sound card and you want to configure it at boot
  time using the ISA PnP tools (read
  <http://www.roestock.demon.co.uk/isapnptools/>), then you need to
  compile the sound card support as a module ( = code which can be
  inserted in and removed from the running kernel whenever you want)
  and load that module after the PnP configuration is finished.  To do
  this, say M here and read <file:Documentation/modules.txt> as well
  as <file:Documentation/sound/README.modules>; the module will be
  called soundcore.o.

  I'm told that even without a sound card, you can make your computer
  say more than an occasional beep, by programming the PC speaker.
  Kernel patches and supporting utilities to do that are in the pcsp
  package, available at <ftp://ftp.infradead.org/pub/pcsp/>.

#
# Is it sane to make the CONFIG_SOUND_OSS part a seperate file (say
# drivers/sound/oss.conf) and include it here from sound.conf?
#

symbol: SOUND_OSS
depends: SOUND
# derived:
type: tristate
menu-caption: OSS sound modules
# menu-depends:
menu-parent: SOUND
description:
  OSS is the Open Sound System suite of sound card drivers. They make
  sound programming easier since they provide a common API. Say Y or M
  here (the module will be called sound.o) if you haven't found a
  driver for your sound card above, then pick your driver from the
  list below.

include drivers/sound/sb.conf
# other card specific configuration files are included here

#
# End of sound configuration file
#

Sound blaster configuration file included by the above file would look like this:

#
# Sound blaster configuration
# drivers/sound/sb.conf
#

maintainer: SB Maintaner <his@email.address> http://his.site.org/homepage/
files: sb.h sb_audio.c sb_card.c sb_common.c sb_ess.c sb_ess.h sb_midi.c \
  sb_mixer.c sb_mixer.h

symbol: SOUND_SB
depends: SOUND_OSS
# derived:
type: tristate
menu-caption: 100% Sound Blaster compatibles
menu-parent: SOUND_OSS
description:
  Answer Y if you have an original Sound Blaster card made by Creative
  Labs or a 100% hardware compatible clone (like the Thunderboard or
  SM Games). For an unknown card you may answer Y if the card claims
  to be Sound Blaster-compatible.

  Please read the file <file:Documentation/sound/Soundblaster>.

  You should also say Y here for cards based on the Avance Logic
  ALS-007 and ALS-1X0 chips (read <file:Documentation/sound/ALS>) and
  for cards based on ESS chips (read
  <file:Documentation/sound/ESS1868> and
  <file:Documentation/sound/ESS>). If you have an SB AWE 32 or SB AWE
  64, say Y here and also to "AWE32 synth" below and read
  <file:Documentation/sound/INSTALL.awe>. If you have an IBM Mwave
  card, say Y here and read <file:Documentation/sound/mwave>.

  If you compile the driver into the kernel and don't want to use
  isapnp, you have to add "sb=<io>,<irq>,<dma>,<dma2>" to the kernel
  command line.

  You can say M here to compile this driver as a module; the module is
  called sb.o.

#
#  NOTE: Next few symbols are from 2.2
#  They are included here to demonstrate some features
#

symbol: SB_BASE
type: hex
default: 0x220
menu-caption: I/O base for SB Check from manual of the card
menu-parent: SOUND_SB
menu-depends: SOUND_SB == "y"

symbol: SB_IRQ
type: int
default: 7
depends: SOUND_SB == "y"
menu-caption: Sound Blaster IRQ Check from manual of the card
menu-parent: SOUND_SB
menu-depends: SOUND_SB == "y"

symbol: SB_DMA
type: int
default: 1
depends: SOUND_SB == "y"
constraints: (SB_DMA == "0") || (SB_DMA == "1") || (SB_DMA == "3")
menu-caption: Sound Blaster DMA 0, 1 or 3
menu-parent: SOUND_SB
menu-depends: SOUND_SB == "y"

symbol: SB_MPU_IRQ
type: int
default: -1
depends: SOUND_SB == "y"
menu-caption: SB MPU401 IRQ (Jazz16, SM Wave and ES1688) Check from manual of the card
menu-parent: SOUND_SB
menu-comment: MPU401 IRQ is only required with Jazz16, SM Wave and ESS1688.
menu-depends: SOUND_SB == "y"
 
#
# End of Sound blaster configuration
#

Config file format

Overview

A config file contains a sequence of lines that are tags, include statements, blank lines or description lines. Tags are either grouped into `block's or stay standalone.

Anything in a line after a hash (#) is ignored. However, the newline character is NOT ignored, therefore lines beginning with # are same as blank lines.

A block is a sequence of tags without blank lines and include statements. Each block describes a symbol and/or a menu-item. Tags start at the first column, i.e., no leading whitespaces.

Stand alone tags describe parameters global to a file such as the maintainer, and related *.[ch] files. They also may appear inside/after blocks.

Including other config files

Including files in kernelconf is different from C include statement. It only tells the processing tool to process the included configuration file. The inclusion is NOT `preprocessed'.

Include path should be given either relative to the kernel source tree or as a full path name.

Include files can be used as a block seperator although this use is not recommanded.

Here is an example:

include drivers/pci/pci.conf
include /home/anuradha/test-driver/test-driver.conf

Standalone tags

The following tags are allowed anywhere in a configuration file. If appeared stand alone, they are relevent to the whole config file, and if appeared inside a block, they correspond only to that block.

maintainer: His Name <his@email.address> http://www.his.home/page/
home-page: http://www.this.driver.org/home/page/
download: ftp://ftp.somewhere.org/pub/driver/location/
changelog: http://www.this.driver.org/home/page/ChangeLog.html
files: file1.c, file1.h, file2.c

If maintaner specifies only his name and home page, they should be seperated with a blank email address, i.e., <>.

See the soundblaster config file above for an example.

Symbols

Symbols are `introduced' with the `symbol:' tag. It should appear only at the beginning of a block. A symbol can have a constant value (frozen), or it can be set by hand and/or derived from the values of other symbols.

Let's look at some examples.

• Symbol X86 is always set to "y" in intel i386 architecture.
• Symbol MODULES is only set by hand.
• Symbol RTC can either be set by hand or is set to "y" if (X86 && SMP) is true.

Types

Symbols should be of one of the following types:

• bool: y or n.
• tristate: y, m or n.
• option: same as bool, except only one of a group can be y.
• int: integer
• hex: same as int, except user doesn't have to use 0x when entering a value and the output is written in hex format.
• char: any character
• string: a null terminated sequence of characters.

Setting values

`Constant' symbols can be set with the tag `value:'. These symbol values should be marked frozen by processing tools, and should not be altered.

The tag `default:' can also be used, but such symbols are not marked frozen.

Here is an example:

#
# i386 configuration file
# arch/i386/i386.conf
#

symbol: X86
value: y
description:
  This is Linux's home port.  Linux was originally native to the Intel
  386, and runs on all the later x86 processors including the Intel
  486, 586, Pentiums, and various instruction-set-compatible chips by
  AMD, Cyrix, and others.

Dependencies

Dependencies for a symbol are listed in a `depends:' tag as expressions seperated by semicolons.

If a dependency of a symbol A is `simple', i.e., contains only a single symbol B, it is expanded so that:

• If both A and B have type tristate, the dependency B is replaced with A <= B. For example, symbol SOUND_SB depends on SOUND_OSS, and this dependency is expaned to SOUND_SB < SOUND_OSS.
• If A is boolean and B is tristate or module, the dependency B is replaced with B != "n". For example, APM_ALLOW_INTS depends on APM, and this expression is expanded to APM != "n".
• If the dependency of a symbol A is a `natural dependency', i.e., a simple dependency on the symbol B corresponding to the parent menu item, the dependency is replaced with a derived value of B. Tools may automatically set B if A is altered. In fact, both the above examples are natural dependencies.

If a dependency expression A of a boolean/tristate/option symbol B does not contain the dependency operator ->, it is expanded to (B > "n") -> A.

The value of symbol cannot be altered unless the change keeps all the expressions in the `depends:' tag evaluated to y.

A menu is displayed either if it does not have a `menu-depends:' tag or if all the expressions of its `menu-depends:' tag are evaluated to y.

Rules

Rules are included with a tag `rules:'. It is similar to depends: tag, except no expansion is done.

Derived Values

All the derived values of a symbol are listed in a `derived:' tag as expressions seperated by semicolons.

Each expression is evaluated in turn and if one returns a value with a non-NULL type, that value is assigned to the symbol and the processing stops.

Expressions

An expressions is a sequence of:

• Identifiers: should contain characters and digits; may begin with a digit. They should refer to either a symbol and/or a menu-item.
• Values: should be contained within double quotes (") or single quotes (').
• Paranthesis: control the order of evaluation.
• Operators: as defined below.

Expressions should be evaluated to one of the following types:

• Boolean: two possible values are {y, n}; n < y
• Tristate: three possible values are {y, m, n}; n < m < y
• Integer: in the same sence as in C
• Character: in the same sence as in C
• String: in the same sence as in C
• NULL: used to indicate that the expression has no value

• NULL is converted to boolean n.
• Integeres are convereted to boolean y if nonzero, n otherwise.
• Empty strings are convereted to boolean n, y otherwise (may be it is more meaningful to convert strings "true", "yes", "y" etc. to "y" and so on.).

• Depends (->):
  • A -> B returns n if (A == y) and ((B == n) or (B == NULL)), y otherwise.
  • A and B should evaluate to boolean values.
  • Return type is boolean.
• Derived (<-):
  • A <- B returns A if (B == y), NULL otherwise.
  • A can be any expression, and B should evaluate to a boolean.
  • Return type is boolean or NULL.
• OR (||):
  • A || B returns max(A, B).
  • A and B are boolean or tristate. It is valid for one to be boolean and the other to be tristate.
  • Return type is boolean if both A and B are boolean, tristate if at least one of them is tristate, NULL if invalid.
  • Operands may be of type NULL and is the same as boolean n.
• AND (&&):
  • A && B returns min(A, B).
  • A and B are boolean or tristate. It is valid for one to be boolean and the other to be tristate.
  • Return type is boolean if both A and B are boolean, tristate if at least one of them is tristate, NULL if invalid.
  • Operands may be of type NULL and is the same as boolean n.
• Equal (==), not equal (!=) and relational operators (<, >, <=, >=):
  • Expressions with type NULL is valid when it makes sense. For example, (FOO != NULL) is a valid statement, and will return y if FOO is not NULL. In boolean operations, a NULL value is converted to an n.
  • Return type is boolean or NULL.
• NOT (!):
  • !A returns n if (A == y) or (A == m), y otherwise.
  • A is a boolean or tristate expresssion.
  • Return type is boolean or NULL.

Operators have the same precedence as in C. Derived and depends have the same precedence as of assignment. All operaters are evaluated from left to right.

Whether the evaluation should be short circuited or not (e.g., in evaluating (A && B), if A is found to be false (n), we can readily return false without ever evaluating B.), is upto the tools. Current tools do complete evaluation of expressions.

Download

Latest snapshot of kernelconf is 0.1.3. Download it here.

IMPORTANT: From version 0.1.3 onwards, symbol files should be downloaded seperately.

• Version 0.1.3 (2002-02-09)

  • Dependency handling (menuconfig)
  • Seperate binaries for each type of config
  • Expanding shorhand notations in dependencies
  • Correct handling of empty expressions
  • Correct handling of line numbers in symbol files
  • Values can also be enclosed in single quotes
  • New tag `rules:' to specify generic constraints
  • Code cleanups and restructuring, as usual ;)
  • Download: kernelconf-0.1.3.tar.gz

• Symbol files

  • symbols-2.5.2-pre9-1.tar.gz

• Version 0.1.2 (2002-01-24)

  • Moved lxdialog from scripts/ to conf/
  • Values defined with "value:" are frozen
  • Almost all the symbols for i386 in .conf files
  • Reading config files
  • Vi compatible up and down movements (j and k) in lxdialog (menuconfig)
  • Integer, hex and character input/read/write (menuconfig)
  • Symbols and menu handling done with a single tree (menuconfig)
  • Made every tristate symbol's module value depend on CONFIG_MODULES
  • Made expression evaluation more sane
  • Better error handling
  • Lots of code cleanups
  • Download: kernelconf-0.1.2.tar.gz

• Version 0.1.1 (2002-01-14)

  • Menu dependancies in menuconfig
  • Expression evaluating (mostly boolean)
  • Expression parsing (almost complete)
  • Fixed menuconfig not to alter parent menu items twice
  • Prompt for saving new configuration on exit
  • Return to parent menu after radio button selection (menuconfig)
  • Radio button menus display current selection (menuconfig)
  • Unlink tempory files created by menuconfig
  • More symbols and dependencies in config files
  • Download: kernelconf-0.1.1.tar.gz

• Version 0.1.0 (2002-01-12)

  • Added menuconfig using lxdialog
  • Added help support (doesn't use Configure.help)
  • Added selection support in ttyconfig
  • Made ttyconfig much better
  • Added more symbols and menu-items to i386.conf file from CML1
  • Added some comments from Configure.help to i386.conf file
  • A lot (too numerous to mention) of code cleanups and bugfixes
  • New bugs ;)
  • Download: kernelconf-0.1.0.tar.gz

• Version 0.0.1 (2002-01-10)

  • Reads and parses symbols and menus from .conf files into a binary tree
  • Menu hiearachy is functional for boolean and tristate symbols
  • make ttyconfig works for boolean and tristate symbols
  • Writing .config and autoconf.h works for boolean and tristate symbols
  • Just a couple of symbols and menu items in the i386.conf file
  • Download: kernelconf-0.0.1.tar.gz