Compiling a kernel Notes

version:

• 2.4:

Currently the standard, at or around version 2.4.26, with more secure versions as low as 2.4.18 (read: woody). kernel development moves in many directions at once, so it's hard to track things. A "major" version with kernels is the "4" in 2.4.26, the "26" is the minor version. (`uname -r` will tell you what you have.) once a minor version is released, security patches will continue to be released on that version to accomodate people who want to work with a stable target, and that will look like '2.4.18-1' or '2.6.5-r2'. This is at the same time as new minor versions of the kernel are being released.

• 2.6:

2.5 was the development branch, and when they decided it was "stable", they released as 2.6. is faster than 2.4, and has some better support for bleeding edge technology. Not considered as stable or secure.

• 2.2:

Cosidered to be super secure as a result of the trial of having been in use for as long as it has. Poor support for very recent hardware.

• patches:

Some people will take a kernel and play with the code to make it do whatever they want. Sometimes this is good (like adding support for weird hardware), and sometimes it's horribly confused and leads to systems that fall apart. They will often release their own patches to the kernel, which is just a file that contains all the differences between the normal kernel and their custom one, which can then be applied by anyone else to make their kernel the same as the custom one. Patches can be accepted into the main branch of the kernel, once the larger community of kernel developers has decided that the changes are acceptible.

Where to get the source:

All linux distributions carry a method for installing the kernel sources - they're required to by law as set down in the Gnu GPL. `apt-cache search kernel-source` will give you plenty of choice on which version you want to play with. www.kernel.org is the official repository for stable kernel releases, and can point you towards where to find development versions as well. Most distributions also have kernels already compiled for most situations, and may absolve your need to compile one at all.These will often be made more general purpose than something you'd make yourself, but with modules, the disadvantage is in the complexity of the setup, which the distros should take care of for you anyway. You can also find a number of patches at http://www.kernel.org/pub/linux/kernel/people/ that belong to people that otherwise do work on the kernel.

configuration:

• make mrproper:

This cleans things up to make sure everything gets built from scratch properly.

• make config/menuconfig/xconfig/gconfig/oldconfig:

You could manually edit the .config file if you wanted, but it's a bunch easier to use one of these configuration helpers. 'oldconfig' tries to make everything the same as it was the last time you tried (useful when changing versions). 'config' and 'menuconfig' are console based, with menuconfig being curses based, and config just being a question and answer interface. 'xconfig' and 'gconfig' are both graphical interfaces.

• builtin vs module:

Are you making this kernel for a known piece of hardware that isn't ever going to change? If so, you can hardcode into the kernel the exact drivers you'll need. There are also a number of things that you know you'll never want to be without.

points of interest:

• drivers:

For all those pieces of hardware you'll be using, like ide hard drives, and sound cards, and video cards, and proprietary death ray controller cards (with closed source kernel patches. blech!). These all come into the kernel as hardware drivers, and you'll need to specify ones that you'll need (builtin), ones that you might use (modules), and ones that you will never use.

• processor:

Are you using an x86 or a PowerPC or a hpux or a dec alpha? do you want hyperthreading? This lets the kernel know what kind of processor you'll be running it on, and some ways you can optimise your use of it.

• filesystems:

You can tell the kernel to understand normal linux-y filesystems like ext3 and reiserfs, and you can tell it to work with some windows formats, and apple formats, and beos formats, and all sorts of others.

• networking:

The kernel takes care of handling the base level of all communications with the external network, like knowing how to speak IPv4 or IPv6 or Appletalk or 802.11b.

• &c.:

Still more things to play with, like profiling and debugging the kernel itself, power management hooks for laptops, or making your kernel preemptive. "code maturity" for instance decides whether or not to display in the kernel config menus any option which is considered unstable. One fun thing to do is to make the minimal kernel for running a system you're on, just to see how small you can get the kernel image.

compiling:

• 2.4: make dep && make bzImage modules modules_install:

That pretty much says what to do, and it takes a long time.

• 2.6: make && make modules_install:

There it is, nice and simple. this'll take a while.

• debian: kpackage:

i don't yet know what this is...

installing:

• bzImage:

This is it, the kernel image ready to boot your system. You need to put it into place, and it's generally nice to name it with the version you compiled it from, and then use a symbolic link to allow for a more generic name. So like, bzImage -> bzImage-2.4.26-1.

• System.map:

This file is used to translate worthless hexidecimal signal codes into readable-esque words. Name the file similarly to the bzImage.

• /boot/:

This is where the kernel and system map go. Put them here and point your boot loader at them and watch it fly.

• modules:

/lib/modules/`uname -r`/kernel is where the kernel keeps all the stuff you didn't compile directly into the image which it can then load on demand (with modprobe or insmod). The `make modules_install` step puts these in place for you.