Recipe 10.8. Patching a Kernel

10.8.1 Problem

You want to add a new feature or correct a problem by patching your kernel, test some new features, or update to the next point release.

10.8.2 Solution

Download and apply the patch to the kernel sources, then compile and build the new kernel. In this example, we are upgrading the 2.6.3 kernel to 2.6.4.

The patch must be in the next-highest directory upstream from your build tree, like this:

$ ls ~/src

linux-2.6.3  patch-2.6.4.bz2

Now change to the top level of your build tree, then unpack and apply the patch:

$ cd linux-2.6.3

$ bzip2 -dc ../patch-2.6.4.bz2 | patch -s -p1

Or, you can do a test drive with the —dry-run option:

$ bzip2 -dc ../patch-2.6.4.bz2 | patch -s -p1 —dry-run

Now configure and build your kernel, and away you go.

Your build tree thoughtfully includes a script to handle applying patches for you, in /scripts/patch-kernel. This is a great little script, especially when you have several patches to apply, because it automatically applies them in the correct order. Usage is simple. From your top-level source directory, run:

$ scripts/patch-kernel

Patches must be applied in order, and you must have all of them. For example, to use patch-2.6.5-rc6, you also need the first five patches in the series (rc1 through rc5). When you're upgrading to a newer point release, you can't skip any of them; all of them have to be applied in sequence.

10.8.3 Discussion

This is what the different patch options mean:

-d

Decompress.

-c

Send output to stdout.

../ patch-2.6.4.bz2

Specifies that the patch file is one directory level up.

-s

Silent output, except for errors.

-p

Strips directory prefixes from the filenames in the patch, also called the "patch level." p1 strips the first prefix from the filepaths in the patch, because it's highly unlikely that you have the same directory structure as the author of the patch. p0 would do a literal copy, and the operation would probably fail.

-s

Successful operation returns no output

Kernel patches come in several flavors. Release candidate (rc) patches are one step removed from being accepted into the stable kernel trees; pre-release (pre) candidates are two steps away. If you're dying to have a new feature and you don't want to wait for the final stable release, rc and pre patches are the way to go. Numbering is seemingly backward: patch-2.6.5-rc3 will wind up in the 2.6.4 kernel.

The official kernel releases on Kernel.org are the "Linus" kernel trees. These are well tested and considered production-ready. Even-numbered kernels are stable releases; odd-numbered kernels are under development. The Linux kernel is actively maintained back to 2.0, and all kernels back to the beginning of Linux are available in the archives.

Each stable kernel has its own maintainer. Linus Torvalds, of course, is the Big Boss of everything. The maintainers of the individual kernels are.

• David Weinehall (2.0)

• Marc-Christian Petersen (2.2)

• Marcelo Tosatti (2.4)

• Andrew Morton (2.6)

Then there are the various kernel trees, run by different maintainers. These are where new designs and features are tested. If they survive, they will eventually be merged into the stable kernel tree. Patches from these have the maintainer's initials appended, as in patch-2.6.5-rc3-mm4. The abbreviations you'll see are:

-ac

Maintainer: Alan Cox. Pending patches for sending to Marcelo (for 2.4 series), and extra add-ons, fixes, etc.

-ck

Maintainer: Con Kolivas. 2.4-based patchset for performance tweaks to the scheduler and vm, and faster desktop performace.

-mm

Maintainer: Andrew Morton. Primarily virtual memory improvements.

-rmap

Maintainer: Rik van Riel. rmap relates to performance and design of virtual memory management.

-aa

Maintainer: Andrea Arcangeli. Virtual memory updates, fixes, and improvements.

-dj

Maintainer: Dave Jones. Forward ports of 2.4 bugfixes to 2.5 series.

-osdl

For the enterprise; large, heavy-use machines and high-performance databases.

10.8.4 See Also

• patch(1)

• Kernel Newbies (http://kernelnewbies.org)

• Kernel.org (http://kernel.org)