Patching the Kernel

It is possible to patch a kernel to the newest Linux kernel version as opposed to downloading the entire source code. This choice can be beneficial for those who are not using a high-speed broadband connection. (A typical compressed kernel source file is nearly 30MB for a download time of about 10 minutes on a 512Kb DSL connection; adjust accordingly for your connection.) Whether you are patching existing sources or downloading the full source, the end results will be identical.

Patching the kernel is not a mindless task. It requires the user to retrieve all patches from her current version to the version she wants to upgrade to. For example, if you are currently running 2.6.1 (and have those sources) and want to upgrade to 2.6.8, you must retrieve the 2.6.2, and 2.6.3 patch sets, and so on. Once downloaded, these patches must be applied in succession to upgrade to 2.6.8. This is more tedious than downloading the entire source, but useful for those who keep up with kernel hacking and want to perform incremental upgrades to keep their Linux kernel as up-to-date as possible.

To patch up to several versions in a single operation, you can use the patch-kernel script located in the kernel source directory for the kernel version you currently use. This script applies all necessary version patches to bring your kernel up to the latest version.

The format for using the patch-kernel script looks like this:

 patch-kernel source_dir patch_dir stopversion 

The source directory defaults to /usr/src/linux if none is given, and the patch_dir defaults to the current working directory if one is not supplied.

For example, assume that you have a 2.6.6 kernel code tree that needs to be patched to the 2.6.8 version. The 2.6.7 and 2.6.8 patch files have been downloaded from ftp.kernel.org and are placed in the /patch directory in the source tree. You issue the following command in the /usr/src/linux-2.6 directory:

 # scripts/patch-kernel /usr/src/linux-2.6.6 /usr/src/linux-2.6.6/patch  

Each successive patch file is applied, eventually creating a 2.6.8 code tree. If any errors occur during this operation, files named xxx# or xxx.rej are created, where xxx is the version of patch that failed. You will have to resolve these failed patches manually by examining the errors and looking at the source code and the patch. An inexperienced person will not have any success with this because you need to understand C programming and kernel programming to know what is broken and how to fix it. Because this was a stock 2.6.6 code tree, the patches were all successfully applied without errors. If you are attempting to apply a nonstandard third-party patch, the patch might likely fail.

When you have successfully patched the kernel, you are ready to begin compiling this code tree as if we started with a fresh, stock 2.6.8 kernel tree.

Using the patch Command

If you have a special, nonstandard patch to apply such as a third-party patch for a commercial product, for example you can use the patch command rather than the special patch-kernel script that is normally used for kernel source updates. Here are some quick steps and an alternative method of creating patched code and leaving the original code alone.

1. Create a directory in your home directory and name it something meaningful, like mylinux.

2. Copy the pristine Linux source code there with

    cp -ravd /usr/src/linux-2.6/* ~/mylinux 

   
   

3. Copy the patch file to that same directory with

    cp patch_filename ~/mylinux 

   
   

4. Change to the ~/mylinux directory with

    cd ~/mylinux 

   
   

5. Apply the patch with

    patch -p1 < patch_filename  > mypatch.log 2>&1  

   
   

   (This last bit of code saves the message output to a file so that you can look at it later.)

6. If the patch applies successfully, you are done and have not endangered any of the pristine source code. In case the newly patched code does not work, you will not have to reinstall the original, pristine source code.

7. Copy your new code to /usr/src and make that special symbolic link described elsewhere in the chapter.