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 development.

Linus 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:

  http://www.bitmover.com/cgi-bin/download.cgi

  Follow the instructions and it will tell you how to download and install BitKeeper.

  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 BitKeeper here:

  http://www.bitkeeper.com/Test.html

• FTP the kernel source from ftp.kernel.org. This is another bandwidth intensive operation, so don't use it if you have a slow link.

  FTP to your local kernel mirror, which is named:

     ftp.<country code>.kernel.org

  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 named:

     linux-2.6.9.tar.gz

  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:

     kernel-source-<version>.<arch>.rpm

  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

When I want to make a patch to send to somebody, I just type:

   $ bk citool
   $ bk -hr<latest revision number> | bk gnupatch > newpatch

   $ bk undo -r<latest revision number>

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 vendor-supplied source.