The Kernel Configuration and Build Process

Starting with the 2.5 series, it's simpler and faster to customize your kernel or add a driver.
Adding a New Configuration Option

To add a new configuration option, simply add new lines to an existing Kconfig file, in the same location as a related configuration option. For example, if a new USB sound device driver is written for the ALSA sound system, it would go into the sound/usb directory, and the sound/usb/Kconfig file would be added. This new device driver controls the mythical FooBar USB speaker device. It depends on having the CONFIG_SND and CONFIG_USB options enabled in addition to the CONFIG_SND_USB_AUDIO option, as the new driver uses some functions found in that driver. The new configuration option should be placed after the SND_USB_AUDIO option but before the closing endmenu command, and it would look something like:

config SND_USB_FOOBAR
    tristate "USB FooBar speaker device driver"
    depends SND_USB_AUDIO
    help
        Say Y here if you want to use FooBar USB
        speaker device.
        This code is also available as a module
        (= code which can be inserted in and
        removed from the running kernel whenever
        you want). The module will be called
        usbfoobar.o.

This option will now show up when the SND_USB_AUDIO option is selected (Figure 4).

Figure 4. The Newly Enabled FooBar USB Speaker Device

Building the Kernel

The kernel is built with a system of individual makefiles that are all linked together when the kernel is built, forming a large makefile. The individual makefiles do not look like any standard makefile, but instead follow a special format that is unique to the kernel build process. The makefile needs to build only the necessary files, depending on the configuration options enabled, in the proper format (as modules or built in to the kernel). As an example, drivers/usb/misc/Makefile in the 2.5.59 kernel release looks like:

#
# Makefile for the rest of the USB drivers
# (the ones that don't fit into any other
# categories)
#
obj-$(CONFIG_USB_AUERSWALD)  += auerswald.o
obj-$(CONFIG_USB_BRLVGER)    += brlvger.o
obj-$(CONFIG_USB_EMI26)      += emi26.o
obj-$(CONFIG_USB_LCD)        += usblcd.o
obj-$(CONFIG_USB_RIO500)     += rio500.o
obj-$(CONFIG_USB_SPEEDTOUCH) += speedtch.o
obj-$(CONFIG_USB_TEST)       += usbtest.o
obj-$(CONFIG_USB_TIGL)       += tiglusb.o
obj-$(CONFIG_USB_USS720)     += uss720.o
speedtch-objs := speedtouch.o atmsar.o

The line:

obj-$(CONFIG_USB_LCD)        += usblcd.o
builds the usblcd.c file into a module if the CONFIG_USB_LCD configuration option is set to m. Otherwise, it is built into the kernel directly if that configuration option is set to y. This step is all that is necessary to add to a kernel makefile if the module is made from only a single .c file.

If the driver consists of multiple .c files, the name of the files needs to be listed on separate lines, along with the name of the module that this driver is called. In the previous example file, this listing of file and driver names looks like:

obj-$(CONFIG_USB_SPEEDTOUCH) += speedtch.o

and

speedtch-objs := speedtouch.o atmsar.o
The first line controls whether the speedtch module is built. If it is, the line indicates whether it is compiled into the kernel or stands as a module. The second line explains that the speedtouch.c and atmsar.c files will be built into .o files and then linked together into the speedtch.o module.

In older kernels, if a file exported symbols, it needed to be explicitly mentioned in the kernel makefiles. In 2.5 and later kernels, that mention is no longer necessary.

Adding a New Driver to the Build Process

To add a new driver to the kernel build process, a single line needs to be added if the driver is contained within a single file. Based on the previous example of the FooBar USB speaker device, the line:

obj-$(CONFIG_SND_USB_FOOBAR) += usbfoobar.o

is added to sound/usb/Makefile.

If the driver is contained in two files, such as foobar1.c and foobar2.c, an additional line needs to be added:

usbfoobar-objs := foobar1.o foobar2.o
Conclusion

The kernel configuration and build process in the 2.5 kernel is much simpler and more flexible than in the previous kernel versions. Thanks go to Roman Zippel and Kai Germaschewski for doing the work to make it easier for kernel developers to focus on writing code and not have to worry about the intricacies of the kernel build process.

A good resource for more information on the specifics of the Kbuild process is available from Sam Ravnborg, at marc.theaimsgroup.com/?l=linux-kernel&m=104162417329638.

Greg Kroah-Hartman is currently the Linux USB and PCI Hot Plug kernel maintainer. He works for IBM, doing various Linux kernel-related things and can be reached at greg@kroah.com.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState