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).
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:
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"The sound/usb/Kconfig file describes all of the ALSA USB driver options, like this:
# 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. endmenuThe # character can be used to comment Kconfig files. Anything written after it on the same line is not read by the configurator, but it is useful for documenting what the file is for and what it should do.
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:
y—the option is enabled.
n—the option is not enabled.
m—the option is set to be built as a module.
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:
bool—the variable can be set only to y or n.
tristate—the variable can be set to y, n or m.
int—the variable can be set to any numeric value.
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.
|Omesh Tickoo and Ravi Iyer's Making Sense of Sensors (Apress)||Apr 21, 2017|
|Low Power Wireless: 6LoWPAN, IEEE802.15.4 and the Raspberry Pi||Apr 20, 2017|
|CodeLathe's Tonido Personal Cloud||Apr 19, 2017|
|Wrapping Up the Mars Lander||Apr 18, 2017|
|MultiTaction's MT Canvus-Connect||Apr 17, 2017|
|Android Candy: Facebook Everything?!?!||Apr 14, 2017|
- Low Power Wireless: 6LoWPAN, IEEE802.15.4 and the Raspberry Pi
- Teradici's Cloud Access Platform: "Plug & Play" Cloud for the Enterprise
- The Weather Outside Is Frightful (Or Is It?)
- Simple Server Hardening
- Understanding Firewalld in Multi-Zone Configurations
- Gordon H. Williams' Making Things Smart (Maker Media, Inc.)
- Bash Shell Script: Building a Better March Madness Bracket
- IGEL Universal Desktop Converter
- A Switch for Your RPi
Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.Get the Guide