10.1. Introduction

Patching, customizing, and upgrading the Linux kernel are useful tasks to master, and they're really not all that scary. These are among the few system maintenence chores that require a reboot, which can be dismaying for those who glory in sustaining long uptimes. Other than that, it's no worse than patching or upgrading any other software.

You'll need kernel sources, and gcc, the GNU C compiler. There are two places to get kernel sources: from your own distribution, or from http://kernel.org. The different Linux distributions modify kernels to varying degrees. Red Hat, SuSE, and Mandrake ship heavily modified kernels. Debian and Slackware mess with them only a little bit. It's possible that installing a vanilla kernel from http://kernel.org will cause things to break on distributions that use modified kernels, so it's better to use kernel sources for your distribution. (See Chapter 2 and Chapter 3 for more information on obtaining and installing Linux software, and Recipe Recipe 4.2 to learn about build tools.)

As with most Linux software, when you patch a kernel, you're not patching your existing kernel; rather, you're patching the sources and building a new binary, so you'll end up with two kernels. This is a good thing, because then you'll have your original kernel to use in the event the new one doesn't boot. You can install as many different kernels as you like, and test the latest releases and different configurations.

When should you modify a kernel?

• To optimize it for your hardware

• To get new functionality

• To remove unneeded functions

• To test new features

• To upgrade

10.1.1 Configuring the New Kernel

Configuration is the most time-consuming part of building a new kernel. It's also the most important. This step is where you decide what hardware, filesystems, power-management features, and other features are going to be supported. There are over a hundred different items to choose from, and there are potentially three decisions to make for each feature: should it be enabled, and if so, as a loadable module or statically compiled into the kernel? As a general rule, if it can be made into a module, do it. This conserves memory, as memory is not allocated for modules until they are actually in use. Also, it's easier to update or add modules than it is to rebuild the whole kernel.

The kernel configurator contains help entries for almost every item. It tells you if a feature can be built as a module, or if it must be built into the base kernel. The help entries describe what each feature is for and advise you what to do with it if you're not sure it should be enabled. If there is no help entry and you don't know what to do, it's safe to enable it. At worst, you'll have a fatter kernel with features you don't use.

The kernel configuration program won't let you make something into a module if it needs to be part of the base kernel, with one important exception: the driver for the disk drive that contains the root filesystem. This must be built into the base kernel, so that the system can boot. Otherwise, you're in a chicken-and-egg situation: drivers are needed to load the root filesystem, but the filesystem cannot be loaded because the drivers are on the filesystem. If you don't build the drivers into the kernel, you'll need to create an initrd image. initrd creates an initial ramdisk that loads the disk drivers, so that the system can boot.

A common misconception is that using loadable modules is slower than building everything into a monolithic kernel. Either way, it simply involves calls to memory locations, so there is no speed difference at all.

Use menuconfig for configuring 2.4 kernels, and use either menuconfig or xconfig for 2.6 kernels. menuconfig is ncurses-based, so you don't need X. If you don't have ncurses, your options are to install it or to use config, which is a seriously dreadful choice. config is the original kernel configurator. It takes forever, and if you make a single mistake you have to start over.

xconfig was completely redesigned for the 2.6 kernel. It's efficient and extremely helpful, containing good help files for every option. You'll need Qt, qt-devel, gtt, and X to run it. Figure 10-1 shows you the xconfig user interface in all its glory. As you can tell, there are lots of optional features you can configure.

Figure 10-1. xconfig user interface

The kernel build tree contains reams of documentation. Look in linux-$VERSION/Documentation/. Also, see linux-$VERSION/README for important installation tips, and read linux-$VERSION/Documentation/Changes for important information on what versions of gcc and other utilities.