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?

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.


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


Kernelconf contains

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.

An example

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  ;))
  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
  <>. 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
  <>), 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 <>.

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


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


Symbols should be of one of the following types:

Type is specified with the `type:' tag. If a type is not given, bool is assumed.

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


An expressions is a sequence of:

Expressions should be evaluated to one of the following types:

Operands are converted to boolean when necessary according to the following rules. Operators are defined as follows where A and B are sub-expressions. Expressions or values of type NULL can be used when it makes sense.

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.


Latest snapshot of kernelconf is 0.1.3. Download it here.

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

Send your comments to Anuradha Ratnaweera (anuradha at taprobane dot org).