The need to patch
In Compiling and Installing a Custom Linux Kernel, I talked about the need for a custom-compiled kernel, and guided you towards making one for yourself. One of the biggest reasons why you’d want to use a custom kernel is if the plain vanilla kernel doesn’t fit your needs somehow. Whether you need to include external drivers, or need an extra feature not bundled in your current kernel, a customized version is the answer. But while the complete feature-set of the Linux kernel is enough for almost everyone, you could be one of the very few who need something which isn’t present in the kernel, custom or not. For those times, you will appreciate the skill of knowing how to patch the kernel source-code.
The patches available for a kernel can include anything from drivers, security enhancements, tweaks, or even low-level changes which completely change the behavior of the kernel. While it’s not particularly smart to go around browsing for patches and picking-and-choosing from the ones available, if you have a particular itch that needs scratching, chances are that someone else has already written a patch which will suffice for your needs.
Driver patches: Many companies (D-Link, Adaptec, etc) tend to release drivers as kernel patches. Other companies release tweaks to their drivers as patches. These patches contain source-code which is merged into the kernel and compiled along with it or as a module. Thus, the newly compiled kernel will have the missing drivers or tweaks.
Low-level changes/Tweaks: Many developers find that they need the kernel to behave in a certain way. Since this need for a different behavior might be for certain rare and specific situations only, the chances of it being integrated into the main kernel are less. To overcome this, the developers release their changes as “patchsets” which can be integrated into a vanilla kernel. Some popular patchsets include the mm, dj, ac, patchsets. These abbreviations are the shortened names of the developers who have written them. Often, the features from these patches are integrated into the main kernel in a later version if the feature is important enough to be included.
If you do find a need for a certain feature/tweak/driver which isn’t included in the vanilla kernel, you could simply go to Google and search for a patch which addresses your needs.
Applying a patch
This guide assumes that you have a clean copy of the kernel source-code unpacked in the /usr/src/linux folder. If you’re unsure about the same, please make your way to this article and follow the guide upto the “Downloading and unpacking…” stage. If you’ve done this correctly, you can now proceed towards downloading your patches and applying them.
But wait! Before you start patching your kernel source-code, here are a couple of things which you should keep in mind:
Patches are almost always built against a specific version of the kernel. So if you’re thinking of using the 2.6.28 kernel, and the patch has been made for version 2.6.24, chances are that the patch might not work the way it should. Try to make sure that the patch is for the same kernel version as the one you’re going to compile.
Patches are built against a clean vanilla kernel. So if you’re thinking of applying patches to a distro-specific kernel package, the result could be unexpected. Always use a clean copy of the kernel source-code from kernel.org to patch.
Always keep a backup of the kernel source-code. If the patch doesn’t work the way it should, you don’t want to go and download the source-code again and unpack it. A simple backup of the source-code folder will save time if you fail.
The patches that you download will be compressed in gz/bzip2 archives. To apply them, you need to copy them to the /usr/src/linux folder. Once that’s done, simply type in this command to integrate the patch into the source-code.
patch -p0 < name-of-patch-file
This will take the patch file as input and feed it to the patch utility, which will integrate it. In case you have an error, chances are that the patch hasn’t been written with the complete folder path. Thus, it could be trying to patch a file called wireless.c which is inside another folder. Since it cannot find this file to patch, the job would fail. An easy way to make sure of this is to simply open the patch file and look at the first few lines. The start of the file will have the name of the file it’s going to patch. All you have to do is find this file within the source-code folder tree and run the patch command from there. That should do it!
Once you’ve patched the kernel source-code, it’s time to customize the kernel and pick-n-choose what features you need. Finally, its time to compile the kernel and use it. Please refer to my previous article here to do the same. Good luck!