Patches

It often is necessary to update the kernel source code, but you should not download the entire tarball every time, since that would be bandwidth-consuming and tedious. Usually, it is sufficient to download a patch that can be applied to an existing kernel tree from within the directory in which the tree is located. For example, if the patch in question has been compressed with bzip2, this can be done in one of the following ways:

$ bzip2 -cd /path/to/patch-2.6.x.bz2 | patch -p1
$ bzcat /path/to/patch-2.6.x.bz2 | patch -p1

If the patch has been compressed with gzip, you can apply it analogously:

$ gzip -cd /path/to/patch-2.6.x.gz | patch -p1
$ zcat /path/to/patch-2.6.x.gz | patch -p1

and for uncompressed patches you can use cat instead of either zcat or bzcat. Of course, these are only the simplest methods of applying patches and it is quite easy to invent some more interesting ones.

It is very useful to be able to revert patches that are no longer needed (or buggy). It can be accomplished by adding the -R flag to the patch command line:

$ bzcat /path/to/patch-2.6.x.bz2 | patch -p1 -R

It is also possible to check if the patch will apply cleanly (ie. it does not contain any pieces of code that will be rejected) with the help of the --dry-run command-line option of patch:

$ bzcat /path/to/patch-2.6.x.bz2 | patch -p1 --dry-run

Then, if there are no messages similar to

1 out of 1 hunk FAILED -- saving rejects to file xxx

the patch can be safely applied.

Most of different versions of the kernel source code are available as sets of patches (patchsets) or even as individual patches that should be applied on top of specific kernel trees. For this reason the patches are labeled in reference with the kernel trees to which they should be applied. Namely, since stable kernel versions are labeled as 2.6.x or 2.6.x.y, development trees are called 2.6.x-git*, 2.6.z-rc* and 2.6.z-rc*-git*, where the -rc patch with z equal to x plus one should be applied on top of the stable kernel 2.6.x. This means, for example, that the patch called patch-2.6.21-rc3.bz2 should be applied on top of the linux-2.6.20 kernel tree and the patch labeled as patch-2.6.21-rc3-git3.bz2 should be applied on top of patch-2.6.21-rc3.bz2.

The following example will hopefully make everything clear. Assume that we have the stable kernel source code labeled as linux-2.6.16.25.tar.bz2 and we want to obtain the development tree 2.6.20-rc1-git1. First, we unpack the tarball:

$ tar xjvf linux-2.6.16.25.tar.bz2

Next, we fetch the patch called patch-2.6.16.25.bz2 from ftp://ftp.kernel.org and revert it:

$ bzip2 -cd /path/to/patch-2.6.16.25.bz2 | patch -p1 -R

Now, we have the sources of the 2.6.16 kernel in our work directory. This is what we wanted, since the stable and development patches only apply cleanly to the 2.6.x kernel trees, as they can contain some code that is also included in the 2.6.x.y versions. Accordingly, we can apply patch-2.6.17.bz2, patch-2.6.18.bz2 and patch-2.6.19.bz2 to our tree:

$ bzip2 -cd /path/to/patch-2.6.17.bz2 | patch -p1
$ bzip2 -cd /path/to/patch-2.6.18.bz2 | patch -p1
$ bzip2 -cd /path/to/patch-2.6.19.bz2 | patch -p1

to obtain the 2.6.19 kernel source code. Finally, we need to download two development patches, patch-2.6.20-rc1.bz2 and patch-2.6.20-rc1-git1.bz2, and apply them in the order specified.

Isn't that easy? Well, it is, but it also is tedious and that is why some people who do not like to lose time use the tool called ketchup (http://www.selenic.com/ketchup/), described in the next section.

It should be noted that patches can only be applied if they are properly formatted. If you receive them via email or download them directly from a mailing list archives, the formatting is often changed in a way that makes them unusable. In such a case patch will refuse to apply the patch and you will see a message like ''patch: **** malformed patch at line''. For instance,

$ cat ../sched-2.patch | patch -p1 -R --dry-run
patching file kernel/sched.c
patch: **** malformed patch at line 33:         if (next == rq->idle)

means that the patch called sched-2.patch is damaged and cannot be reverted. Fortunately, if the patch has been posted to the Linux Kernel Mailing List (LKML), it can be downloaded from the archives at http://marc.theaimsgroup.com/?l=linux-kernel in the original form. For this purpose you only need to find the message that contains the patch and click on the link ''Download message RAW''. Still, even this will not work if the original ''raw'' message containing the patch is malformed.

For more information on downloading and applying patches please see the files README and Documentation/applying-patches.txt in the kernel sources.