The Kernel Configuration and Build Process

The process of building a kernel has two parts: configuring the kernel options and building the source with those options. In versions before the 2.5 kernel, configuration was driven by a Config.in file within every subdirectory and a main help file, Documentation/Configure.help. The language used to describe the build process was based loosely on a shell-style language that would control which configuration options were presented to the user, depending on which options were currently presented.

This worked reasonably well, but over time the variety of different options in the kernel stretched the language beyond what it could reasonably handle. In the 2.5.45 kernel release, Roman Zippel's rewrite of the configuration language and configuration programs was placed in the main kernel tree. The new configuration language is much more flexible and powerful. It also unifies the help text with the configuration logic, making it easier to apply patches for individual drivers, without having to worry about conflicts within a single Configuration.help file.

Also during the 2.5 series, Kai Germaschewski and the other kbuild developers slowly reworked makefile logic within the kernel, making it easier to build the kernel based on the selected options. This article describes the format of the makefile and configuration files in the 2.5 kernel and shows how to add a new driver to the build process.

To configure different kernel options, a user runs either a text-mode or a graphical kernel configurator. The text-mode configurator can be run with make config and prompts the user to select configuration options in order (Figure 1). The ncurses text version is more popular and is run with the make menuconfig option (Figure 2). The graphical configurator is run with make xconfig and uses Qt as the widget set (Figure 3).

Figure 1. Configuring the Kernel with make config

Figure 2. make menuconfig makes it easier to back up and correct mistakes.

Figure 3. The Qt-Based make xconfig

When the kernel configurator is run, it reads the main kernel configuration file, located in arch/i386/Kconfig for the i386 platform. Other architectures have the main configuration files located in their main directories. This main configuration file then includes other configuration files from the different subdirectories in the kernel directory tree. Those configuration files also can include other configuration files as needed. For example, the arch/i386/Kconfig file contains the line:

source "sound/Kconfig"

which will read information from that file. This sound/Kconfig file then includes a lot of other files:

source "sound/core/Kconfig"
source "sound/drivers/Kconfig"
source "sound/isa/Kconfig"
source "sound/pci/Kconfig"
source "sound/ppc/Kconfig"
source "sound/arm/Kconfig"
source "sound/usb/Kconfig"

# ALSA USB drivers
menu "ALSA USB devices"
    depends on SND!=n && USB!=n

config SND_USB_AUDIO
    tristate "USB Audio/MIDI driver"
    depends on SND && USB
    help
      Say 'Y' or 'M' to include support for
      USB audio and USB MIDI devices.
endmenu

The menu and endmenu commands tell the configurator to declare a new menu level or new screen in some of the configuration programs. On the menu line, the name of the menu should be specified within “ characters. For this file, the menu is called "ALSA USB devices".

Menus and configuration options can be controlled to display or not. In this example, the USB option menu is only displayed if the CONFIG_SND and CONFIG_USB options are selected, which is controlled by the line depends on SND!=n && USB!=n. To help decrease the amount of typing involved, all configuration options automatically start with CONFIG, which is not used within the configuration language. The valid states for a configuration option are:

If both the CONFIG_SND and CONFIG_USB options are not set to n (meaning they are set either to be built in to the kernel or to build as a module), the CONFIG_SND_USB_AUDIO option is presented to the user. This option can be set to one of the three values, and it is described as a “tristate” value. The text that should be shown to the user is "USB Audio/MIDI driver":

tristate "USB Audio/MIDI driver"

The valid values for describing a configuration variable are:

This configuration option is controlled by a depends logic line, which follows the same logic as a menu option. The CONFIG_SND_USB_AUDIO option depends on both the CONFIG_SND and CONFIG_USB options, meaning that if one of these options is set to a module, then the CONFIG_SND_USB_AUDIO option also should be set to a module. If both of the controlling options are not enabled (meaning both are set to n), this option will not be displayed. If both of these options are set to y, this option can be selected as n, y or m. All of this is defined with the simple line:

depends on SND && USB

Within the kernel code, the configuration variable will be seen (the CONFIG_SND_USB_AUDIO in the above example), so the code can test for it or any other kernel configuration option's existence. However, using #ifdef within a .c file to test for different configuration options is against the kernel-style programming guidelines, which I covered in my article “Proper Linux Kernel Coding Style” [LJ, July 2002, www.linuxjournal.com/article/5780]. Instead, limit the use of #ifdef to .h files, keeping the .c files cleaner and easier to read.

Previously, the help text for a configuration option was placed in one big Configuration.help file. Now the help text is placed right after the depends line within the Kconfig file. It begins with a line containing either help or ---help---, followed by a number of lines of help text that are indented two spaces from the help line.