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

In some situations, such as building a kernel on an embedded system without graphics, using the command line configuration utility is unavoidable, but this author would go to great lengths to find a way around it.

The kernel-configuration subsystem uses several graphical front ends. In fact, a recent Linux kernel release included 10 such configuration targets. They are summarized here, from text taken directly from the output of make help :

• config Update current config using a line-oriented program

• menuconfig Update current config using a menu-based program

• xconfig Update current config using a QT-based front end

• gconfig Update current config using a GTK-based front end

• oldconfig Update current config using a provided .config as the base

• randconfig New config with random answer to all options

• defconfig New config with default answer to all options

• allmodconfig New config that selects modules, when possible

• allyesconfig New config in which all options are accepted with yes

• allnoconfig New minimal config

The first four of these makefile configuration targets invoke a form of configuration editor, as described in the list. Because of space considerations, we focus our discussion in this chapter and others only on the GTK-based graphical front end. Realize that you can use the configuration editor of your choice with the same results.

The configuration editor is invoked by entering the command make gconfig from the top-level kernel directory. [31] As mentioned, you can use the configuration editor of your choice, such as make xconfig or make menuconfig. Figure 4-2 shows the top-level configuration menu presented to the developer when gconfig is run. From here, every available configuration parameter can be accessed to generate a custom kernel configuration.

Figure 4-2. Top-level kernel configuration

When the configuration editor is exited, you are prompted to save your changes. If you elect to save your changes, the global configuration file .config is updated (or created, if it does not already exist). This .config file, introduced earlier, drives the kernel build via the top-level makefile. You will notice in this makefile that the .config file is read directly by an include statement.

Most kernel software modules also read the configuration indirectly via the .config file as follows. During the build process, the .config file is processed into a C header file found in the .../include/linux directory, called autoconf.h. This is an automatically generated file and should never be edited directly because edits are lost each time a configuration editor is run. Many kernel source files include this file directly using the #include preprocessor directive. Listing 4-6 reproduces a section of this header file that corresponds to the earlier USB example above. Note that, for each entry in the .config file snippet in Listing 4-5, a corresponding entry is created in autoconf.h. This is how the source files in the kernel source tree reference the kernel configuration.

Listing 4-6. Linux autoconf.h

/*

* USB support

*/

#define CONFIG_USB_MODULE 1

#undef CONFIG_USB_DEBUG

/*

* Miscellaneous USB options

*/

#define CONFIG_USB_DEVICEFS 1

#undef CONFIG_USB_BANDWIDTH

#undef CONFIG_USB_DYNAMIC_MINORS

/*

* USB Host Controller Drivers

*/

#define CONFIG_USB_EHCI_HCD_MODULE 1

#undef CONFIG_USB_EHCI_SPLIT_ISO

#undef CONFIG_USB_EHCI_ROOT_HUB_TT

#define CONFIG_USB_OHCI_HCD_MODULE 1

#define CONFIG_USB_UHCI_HCD_MODULE 1

If you haven't already done so, execute make gconfig in your top-level kernel source directory, and poke around this configuration utility to see the large number of subsections and configuration options available to the Linux developer. As long as you don't explicitly save your changes, they are lost upon exiting the configuration editor and you can safely explore without modifying your kernel configuration. [32] Better yet, make a backup copy of your .config file. Many configuration parameters contain helpful explanation text, which can add to your understanding of the different configuration options.

If you type make help at the top-level Linux source directory, you are presented with a list of targets that can be generated from the source tree. The most common use of make is to specify no target. This generates the kernel ELF file vmlinux and is the default binary image for your chosen architecture (for example, bzImage for x86). Specifying make with no target also builds all the device-driver modules (kernel-loadable modules) specified by the configuration.

Many architectures and machine types require binary targets specific to the architecture and bootloader in use. One of the more common architecture specific targets is zImage. In many architectures, this is the default target image that can be loaded and run on the target embedded system. One of the common mistakes that newcomers make is to specify bzImage as the make target. The bzImage target is specific to the x86/PC architecture. Contrary to popular myth, the bzImage is not a bzip2 -compressed image. It is a big zImage. Without going into the details of legacy PC architecture, it is enough to know that a bzImage is suitable only for PC-compatible machines with an industry-standard PC-style BIOS.

Listing 4-7 contains the output from make help from a recent Linux kernel. You can see from the listing that many targets are available in the top-level Linux kernel makefile. Each is listed along with a short description of its use. It is important to realize that even the help make target (as in make help) is architecture specific. You get a different list of architecture-specific targets depending on the architecture you pass on the make invocation. Listing 4-7 illustrates an invocation that specifies the ARM architecture, as you can see from the make command line.

Listing 4-7. Makefile Targets

$ make ARCH=arm help

Cleaning targets:

clean - remove most generated files but keep the config

mrproper - remove all generated files + config + various backup files

Configuration targets:

config - Update current config utilising a line-oriented program

menuconfig - Update current config utilising a menu based program

xconfig - Update current config utilising a QT based front-end

gconfig - Update current config utilising a GTK based front-end

oldconfig - Update current config utilising a provided .config as base

randconfig - New config with random answer to all options

defconfig - New config with default answer to all options

allmodconfig - New config selecting modules when possible

allyesconfig - New config where all options are accepted with yes

allnoconfig - New minimal config

Other generic targets:

all - Build all targets marked with [*]

* vmlinux - Build the bare kernel

* modules - Build all modules