Christopher Hallinan - Embedded Linux Primer - A Practical, Real-World Approach

Now that you've seen how the build system controls the kernel image, let's take a look at a representative kernel subdirectory. Listing 4-4 details the contents of the mach-ixp425 subdirectory. This directory exists under the .../arch/arm architecture-specific branch of the source tree.

Listing 4-4. Kernel Subdirectory

$ ls -l linux-2.6/arch/arm/mach-ixp425

total 92

-rw-rw-r-- 1 chris chris 11892 Oct 10 14:53 built-in.o

-rw-rw-r-- 1 chris chris 6924 Sep 29 15:39 common.c

-rw-rw-r-- 1 chris chris 3525 Oct 10 14:53 common.o

-rw-rw-r-- 1 chris chris 13062 Sep 29 15:39 common-pci.c

-rw-rw-r-- 1 chris chris 7504 Oct 10 14:53 common-pci.o

-rw-rw-r-- 1 chris chris 1728 Sep 29 15:39 coyote-pci.c

-rw-rw-r-- 1 chris chris 1572 Oct 10 14:53 coyote-pci.o

-rw-rw-r-- 1 chris chris 2118 Sep 29 15:39 coyote-setup.c

-rw-rw-r-- 1 chris chris 2180 Oct 10 14:53 coyote-setup.o

-rw-rw-r-- 1 chris chris 2042 Sep 29 15:39 ixdp425-pci.c

-rw-rw-r-- 1 chris chris 3656 Sep 29 15:39 ixdp425-setup.c

-rw-rw-r-- 1 chris chris 2761 Sep 29 15:39 Kconfig

-rw-rw-r-- 1 chris chris 259 Sep 29 15:39 Makefile

-rw-rw-r-- 1 chris chris 3102 Sep 29 15:39 prpmc1100-pci.c

The directory contents in Listing 4-4 have common components found in many kernel source subdirectories: Makefile and Kconfig. These two files drive the kernel configuration-and-build process. Let's look at how that works.

The Linux kernel configuration and build system is rather complicated, as one would expect of software projects containing more than six million lines of code! In this section, we cover the foundation of the kernel build system for developers who need to customize the build environment.

A recent Linux kernel snapshot showed more than 800 makefiles [29] Not all these makefiles are directly involved in building the kernel. Some, for example, build documentation files. in the kernel source tree. This might sound like a large number, but it might not seem so large when you understand the structure and operation of the build system. The Linux kernel build system has been significantly updated since the days of Linux 2.4 and earlier. For those of you familiar with the older kernel build system, we're sure you will find the new Kbuild system to be a huge improvement. We limit our discussion in this section to this and later kernel versions based on Kbuild.

Introduced earlier, the dot-config file is the configuration blueprint for building a Linux kernel image. You will likely spend significant effort at the start of your Linux project building a configuration that is appropriate for your embedded platform. Several editors, both text based and graphical, are designed to edit your kernel configuration. The output of this configuration exercise is written to a configuration file named .config, located in the top-level Linux source directory that drives the kernel build.

You have likely invested significant time perfecting your kernel configuration, so you will want to protect it. Several make commands delete this configuration file without warning. The most common is make mrproper. This make target is designed to return the kernel source tree to its pristine, unconfigured state. This includes removing all configuration data from the source treeand, yes, it deletes your .config.

As you might know, any filename in Linux preceded by a dot is a hidden file in Linux. It is unfortunate that such an important file is marked hidden; this has brought considerable grief to more than one developer. If you execute make mrproper without having a backup copy of your .config file, you, too, will share our grief. (You have been warnedback up your .config file!)

The .config file is a collection of definitions with a simple format. Listing 4.5 shows a snippet of a .config from a recent Linux kernel release.

Listing 4-5. Snippet from Linux 2.6 .config

...

# USB support

#

CONFIG_USB=m

# CONFIG_USB_DEBUG is not set

# Miscellaneous USB options

#

CONFIG_USB_DEVICEFS=y

# CONFIG_USB_BANDWIDTH is not set

# CONFIG_USB_DYNAMIC_MINORS is not set

# USB Host Controller Drivers

#

CONFIG_USB_EHCI_HCD=m

# CONFIG_USB_EHCI_SPLIT_ISO is not set

# CONFIG_USB_EHCI_ROOT_HUB_TT is not set

CONFIG_USB_OHCI_HCD=m

CONFIG_USB_UHCI_HCD=m

...

To understand the .config file, you need to understand a fundamental aspect of the Linux kernel. Linux has a monolithic structure. That is, the entire kernel is compiled and linked as a single statically linked executable. However, it is possible to compile and incrementally link [30] Incremental linking is a technique used to generate an object module that is intended to be linked again into another object. In this way, unresolved symbols that remain after incremental linking do not generate errorsthey are resolved at the next link stage. a set of sources into a single object module suitable for dynamic insertion into a running kernel. This is the usual method for supporting most common device drivers. In Linux, these are called loadable modules . They are also generically called device drivers. After the kernel is booted, a special application program is invoked to insert the loadable module into a running kernel.

Armed with that knowledge, let's look again at Listing 4-5. This snippet of the configuration file (.config) shows a portion of the USB subsystem configuration. The first configuration option, CONFIG_USB=m, declares that the USB subsystem is to be included in this kernel configuration and that it will be compiled as a dynamically loadable module (=m), to be loaded sometime after the kernel has booted. The other choice would have been =y, in which case the USB module would be compiled and statically linked as part of the kernel image itself. It would end up in the .../drivers/built-in.o composite binary that you saw in Listing 4-3 and Figure 4-1. The astute reader will realize that if a driver is configured as a loadable module, its code is not included in the kernel proper, but rather exists as a stand-alone object module, a loadable module , to be inserted into the running kernel after boot.

Notice in Listing 4-5 the CONFIG_USB_DEVICEFS=y declaration. This configuration option behaves in a slightly different manner. In this case, USB_DEVICEFS (as configuration options are commonly abbreviated) is not a stand-alone module, but rather a feature to be enabled or disabled in the USB driver. It does not necessarily result in a module that is compiled into the kernel proper (=y); instead, it enables one or more features, often represented as additional object modules to be included in the overall USB device driver module. Usually, the help text in the configuration editor, or the hierarchy presented by the configuration editor, makes this distinction clear.

Early kernels used a simple command line driven script to configure the kernel. This was cumbersome even for early kernels, in which the number of configuration parameters was much smaller. This command line style interface is still supported, but using it is tedious, to say the least. A typical configuration from a recent kernel requires answering more than 600 questions from the command line, entering your choice followed by the Enter key for each query from the script. Furthermore, if you make a mistake, there is no way to back up; you must start from the beginning again. That can be profoundly frustrating if you make a mistake on the 599th entry!