Working with Kconfig

The Kconfig mechanism is today’s standard configuration mechanism and it is used by leading open source projects, such as the Linux kernel, Busybox and uClibc. The Kconfig has a basic configuration syntax that allows you to add configuration options of various types, create dependencies and write a few lines of description. The Kconfig utilities know how to read and parse the configuration files, and create project configuration files (usually by the name of .config for Makefiles and autoconf.h for source files). Other advantages this method has, are automatic menu generation (for both graphical and text based consoles), and ease of configuration management. With Kconfig, there is no need to specify any build flags to the project’s make. In this article I will show how to use the Kconfig to configure your Linux kernel, and how to easily modify the kernel’s Kconfig files in order to add a new driver somewhere in the tree. These methods of configuration can be also ported to any other projects.

The Linux kernel is instrumented with a Kconfig file almost per each directory. Each Kconfig file configures its own level. For example, you’ll find a Kconfig in each driver directory or arch directory. Each one of them configures a driver or architecture and includes other Kconfig files in the levels below it.

Configuring the Linux Kernel

There are 4 main ways to configure the kernel:

• Running “make menuconfig”: Will show a text based menu configuration of the kernel. It also applicable for configuring a Linux kernel using telnet/ssh connections to a build server. This configuration option will read the existing configuration in case it exists. Otherwise, it will initialize all the menu items with their default values. When browsing in the menus, you could see that some configuration options are not marked, some are mark with star [*] and some are marked with [M]. These options mean: Disabled, Enabled and Modulized, accordingly. The difference between Enabled and Modulized, is the fact that when a driver or a feature is Enabled, it will be loaded automatically with the kernel, as an integral part of it without an option to remove. The Modulized option enables hot plug and unplug of the driver/feature, thus allowing you to use the memory for other tasks, in case it is not required.

Screenshot: menuconfig (textual configuration menu)

• Running “make xconfig”: Similar to option 1, but uses a graphical interace. It will not work with telnet/ssh connections, and it requires the “qt3-devel” package to be installed in the machine.

Screenshot: xconfig (graphical configuration menu)

• Running “make defconfig”: Will read and parse all the configuration files and assign default values to the configuration variables. In case a default value is not available, the program will prompt for a selection.
• Running “make oldconfig”: In case you were editing the configuration file (.config) manually, it is required to run this command in order for the setting to take effect.

The Kconfig syntax

The Kconfig syntax is very simple and it is documented in the Documentation/kbuild/kconfig-language.txt file. Let’s review some of the basics by a few examples:

• An example from drivers/video/Kconfig:

The example, defines a new variable in the name of CONFIG_FB_CIRRUS (note that the CONFIG_ prefix is added automatically and should be omitted from the Kconfig file itself). Let’s jump to the help section for a second. We can read that this configuration option enables support for various Cirrus Logic video cards. In the second line, we can see that this variable is in the type of “tristate”. It means that this configuration option has 3 possible states; Disabled, Enabled and Modulized. Each configuration option must have a type. The available types are: “bool“, “tristate“, “string“, “hex” or “int“. Each type has its own properties. The bool type can be either Enabled or Disabled. The string type will contain a list of characters. The hex type will contain a hexadecimal representation of a number (usually used to assign hardware address and ids) and the int type contains numbers. Right next to the type, you’ll find the prompt string that represents the configuration option in the menu (or in the prompt). Next, shows the dependency of this configuration option. It means that this option will not be available for selection if the CONFIG_FB option is not enabled and either CONFIG_ZORRO or CONFIG_PCI are enabled. In this way, the driver developer can be sure that this driver will not be available unless the Frame Buffer framework is enabled and the target has either Zorro or PCI interfaces enabled (otherwise, the driver will fail to compile or run). The next lines, with the select option, show options that the driver needs in order to operate correctly. In this example, we see that the driver requires a few Frame Buffer options to be enabled.

• An example from net/Kconfig:

This example shows how to create a submenu. In this example, a sub menu in the name of “Networking options” will be created, and a bunch of related configuration options will be placed inside it. This menu also includes some other Kconfig files using the keyword “source”.

You can browse the Kconfig files in the kernel and learn from the many examples available. That’s the best way to learn.

Adding a new configuration option

In order to add a new driver or feature to the Kernel, first we’ll need to select the appropriate location inside the tree to store the code. Once selected, we’ll need to add a new configuration option in the corresponding Kconfig file, and update the directory’s Makefile to compile our new code, once our configuration option has been selected.

For our example, let’s add a new driver under the networking drivers. In the following example, our new driver contains two files; my_obj_file1.c and my_obj_file2.c. In order to add this driver in the kernel, we need to do the following:

• Select a unique configuration option name, (or names, in case the driver/feature has additional configuration parameters). Otherwise, there will be a collision and a configuration mess. You can grep the .config file to make sure your selected name is not taken. For this example, the name is CONFIG_RT_EMBEDDED_TEST_DRIVER.
• Define the configuration option type(s). The main feature/driver can be Boolean type (Enabled/Disabled), or Tristate type (Enabled/Disabled/Modulized). Other configuration types are driver specific (like hardware address, number of buffers, identification string, etc.).
• Edit the appropriate Kconfig file. In this example, we will edit the drivers/net/Kconfig file:

• Next, we add our new configuration option in the appropriate Makefile in order to build the code when it is enabled. In this example, we will edit the drivers/net/Makefile:

• Now the new driver is a part of the Linux kernel. In the next step we must re-configure the kernel because its configuration has been upgraded with a new feature. We can use either configuration possibilities listed in the begining of this article, except for option 4 (its a new configuratin option which is not listed in the default configuration file yet). When using either menu configuration options, the new item will appear with [NEW] marking near it. When using oldconfig option, it will prompt for your selection, while capitaling the default option. In our example, since the default mode is Modulized, we will see n/y/M.

• Here we need to select what to do with the new option, according to our requirements.

Resources

• Kconfig description: http://lxr.linux.no/linux+v2.6.34.1/Documentation/kbuild/kconfig.txt
• The Kconfig language: http://lxr.linux.no/linux+v2.6.34.1/Documentation/kbuild/kconfig-language.txt

Check out the ads, there could be something that may interest you there. The ads revenue helps me to pay for the domain and storage.