Kernel Hacking Lesson #1: Get the Source
Now, you need to get the Linux source. There are many different ways
of getting the Linux source, but I'll list them in order of
preference. You only need to choose one of these options.
While it's easiest to just install the source on your
distribution CD, you'll need to stay up to date with the latest
version of the Linux source if you want to participate in kernel
recommends not having a /usr/src/linux symbolic link to your
kernel source tree.
However, the /usr/src/linux link will sometimes be used as a default
by some modules that compile outside the kernel. If you need it, make sure it
points to the correct kernel tree. If it doesn't, modules that compile outside
the kernel may use the wrong header files.
Use BitKeeper to clone a Linux source repository. This is what I
use, and it's what many other kernel hackers use, including the
entire PowerPC team, Ted T'so, Rik van Riel, and Linus
himself. Be warned, this requires downloading many megabytes of data,
so don't use it if you have a slow link. This option also requires at
least 1 GB of free disk space, which is significantly more than
the other options.
First, get BitKeeper:
Follow the instructions and it will tell you how to download and
Then, clone the main Linux tree using BitKeeper:
$ cd /usr/src
(or wherever you would like to work)
$ bk clone bk://linux.bkbits.net/linux-2.6 linux-2.6
$ cd linux-2.6
$ bk -r co
And now you have a kernel source tree! Learn more about how to use
FTP the kernel source from ftp.kernel.org. This is another
bandwidth intensive operation, so don't use it if you have a slow
FTP to your local kernel mirror, which is named:
For example, I live in the US, so I do:
$ ftp ftp.us.kernel.org
Login (if necessary) with username ftp or anonymous. Change
directory to pub/linux/kernel/v2.6 and download the latest kernel.
For example, if the latest version is 2.6.9, download the file
Usually there is a file named LATEST-IS-<version> to tell you what
the latest version is. I recommend the gzipped format (filename
ending in .gz) instead of bzip2 format (filename ending in
.bz2) since bzip2 takes a long time to decompress.
Untar and uncompress the file in the directory where you are
planning to work.
You now have your Linux kernel source.
Install the kernel source from your distribution CD. If you
already have a directory named /usr/src/linux and it contains more
than one directory, you already have the source installed. If you
don't, read on.
Mount your installation CDROM. On a RedHat based system, the
source RPM is usually in <DistributionName>/RPMS/ and is named:
One way to find the kernel source package is to run this command,
assuming your CD is mounted at /mnt/cdrom:
$ find /mnt/cdrom -name \*kernel-\*
Install the RPM using:
$ rpm -iv <pathname>/kernel-source-<version>.<arch>.rpm
The v switch will tell you if it fails or not.
If your system is not RPM-based, please let us know how to install
the kernel source from your distribution CD.
There are various other ways to get the kernel source, involving
CVS or rsync. If you would like to write instructions for one of
these other methods of getting the kernel source, go ahead and
we'll include them here.
Why do I recommend BitKeeper over ftp, and ftp over vendor source?
BitKeeper handles creating patches for you. (A patch contains the
differences between one source tree and another source tree.)
BitKeeper also applies the latest changes for you. When I want to
update my tree, I just type:
$ bk pull
And most of the time, it just works. The only time I have to do work
is if I have written code that conflicts with the new code downloaded
from the parent tree.
When I want to make a patch to send to somebody, I just type:
$ bk citool
$ bk -hr<latest revision number> | bk gnupatch > newpatch
When I want to undo my latest changes, I type:
$ bk undo -r<latest revision number>
BitKeeper has all kinds of pretty GUI tools to make debugging and
merging code easier.
I like BitKeeper so much I wrote a paper about it. You can find
the paper and some slides on my web page:
I prefer the vanilla kernel source from ftp.kernel.org over the vendor
source because you never know what changes the vendor has made to the
source. Most of the time, the vendor has improved the tree, but often
they make changes of dubious value to a kernel hacker. For example,
RedHat 6.2 shipped a kernel that compiled differently depending on
whether you were running an SMP kernel at the time of compilation.
This makes sense if you are just recompiling a kernel for that
machine, but it was useless if you were trying to compile a kernel for
a different machine.
The other reason to use vanilla source instead of vendor source is if
you want to create and send patches to other kernel developers. If
you create a patch and send it to the Linux kernel mailing list for
inclusion in the main kernel tree, it had better be against the latest
vanilla source tree. If you create a patch on a vendor source tree,
it's unlikely to apply to a vanilla source tree.
The one place where vendor source is crucial is for non-x86
architectures. The vanilla source almost never builds and boots on an
architecture other than x86. Often, the best place to get a working
kernel for a non-x86 is the vendor source. Each architecture usually
has some quirky way of getting the latest source in addition to the