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.
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.
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 <email@example.com> 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 #
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 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
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 <firstname.lastname@example.org> 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 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:
`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 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.
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:
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.