By Jay Fougere
Contributing Writer
Article Date: 05.01.02
Today we have a brief article covering the basics of preparing to
compile a Linux kernel. This is by no means a definitive guide for
building a kernel. For that there is the recently updated (Jan., 2002)
Linux Kernel How-to, by Brian Ward, which can be found here: http://www.linux.org/docs/ldp/howto/Kernel-HOWTO.html
As it turns out, much of what I have learned about building a Linux
kernel I learned through trial and error. I bet that I built over
10 kernels on my old 486SX-25 before I ever got one to boot. If
I remember correctly, it took something like 3 or 4 hours to compile
a kernel on that machine.... imagine my disappointment when it wouldn't
boot!
Now, I can compile a kernel in about three minutes (not including
the time it takes to configure, of course!) on my current machine
(dual PIII 1Ghz w/ 1.5Gb RAM ;), so I am much more willing to try
new things with the kernel. It still takes over an hour on my laptop
(266Mhz w/96M RAM), so I am a little more selective about what I
will try.
Before we get too far, let's take a look at what exactly the kernel
is. The Linux kernel is the core of the Linux operating system.
The file systems are defined here, most of your hardware drivers
are found here, and the lowest level services, such as TCP/IP, PPP,
routing, and so on, are defined here. In other words, it is the
software that interprets instructions from higher level software
into instructions that your specific hardware can understand.
If you are running fairly new hardware (600Mhz+ with 128Mb+RAM)
and it is not busy running other applications, you should be able
to compile a kernel in a reasonably short amount of time (under
a half an hour).
Before we get started with the nuts and bolts of building a kernel,
let's take a look at why you may want/need to build a new kernel.
The most obvious reason to build a new kernel is to add new hardware
to your system. You may also need services such as SCSI emulation
for CD burning or IP tables and IP filters for firewalls configured
into the kernel. I learned early on that immediately following an
installation there were features configured into the OEM kernel
which I did not need and options that were not configured that I
did need.
Once you have decided that you do need to build a new kernel, document
all of your hardware. You will have to have intimate knowledge of
your hardware when you configure your new kernel. Rather than waste
time building kernel after kernel because you cannot get yours to
boot, try to know exactly what you are building your kernel for,
and what you hope to accomplish.
If you happen to be running Windows (in a dual boot configuration
or through removable drives), there is an excellent program by SiSoft
called Sandra that will tell you more than you probably need to
know about your hardware. SiSoft's Sandra Standard is a free download
and can be found here: http://www.sisoftware.demon.co.uk/sandra/
With Windows, you can also look at all of the entries in Device
Manager, although they will not provide as much information as Sandra.
On the other hand, if you are already running Linux with KDE, you
can look in the Control Center in the information section for your
hardware. You can also run 'lsmod' from the command line. This will
list all of the modules currently installed in your kernel.
This brings me to an interesting point. For each kernel configuration
option, you will be presented with one of three choices (we will
discuss the methods of configuration later :). You can either build
the option into the kernel itself, not build it at all, or build
it as a module. A module is a piece of code that can be inserted
into the kernel after it is already running. On a side note, many
device drivers can be compiled as module and inserted into a running
kernel with 'insmod', rather than compiling an entire kernel.
The reason that you would want to use modules is to keep the size
of the kernel small. If you go through and select 'Y' for all of
your options, you are going to have a *huge*, hard to manage kernel.
You will also make a kernel that is too big to fit on a floppy disk.
In other words, you will not be able to make a boot floppy with
that kernel. Keep in mind that the smaller the kernel, the faster
it will run (under most circumstances).
In order to build a kernel, you will need the kernel source code.
Normally this will come with your distribution. For your first kernel,
I recommend building a kernel that is the same version as what your
distribution includes. This is to avoid any compatibility problems
between software you have already installed and the version of the
kernel that it supports. After you have compiled a few kernels,
you will know what your problem areas are and you will be able to
work through these situations.
It is important to take a look at the versioning system that is
used for the Linux kernel. All Linux kernels are given a version
number that comprises three integers, X.Y.Z. The first number (X)
is the major version number, the second number (Y) is the minor
version number and the last number (Z) is the patch level.
The minor version number is an important one to take a look at.
If it is an odd number, then the kernel is an experimental (or "beta")
kernel. For instance, before the 2.4.Z kernels were officially released,
the development kernels that were implementing the features of the
2.4 kernel were 2.3.Z kernels. For your first kernel, steer clear
of any unstable (beta) kernel versions.
Linux distributions commonly patch (change and/or add code to some
of the source code) the kernel for their respective distributions.
For this reason, I recommend that you use a kernel version available
from your distribution, rather than one from http://www.kernel.org
.
A good example of this is the kernel that is included with RedHat
7.2. When I installed RedHat 7.2, I installed with the ext3 file
system. As it turns out, the version of the kernel that I wanted
to upgrade to (I believe it was 2.4.12...) had to be patched to
offer support for the ext3 file system. However, there was a version
of the kernel available from RedHat's FTP site that was newer than
the kernel that I had and was already patched by RedHat to support
the ext3 file system.
Let me also note that not all distributions patch their kernels.
In those cases (Debian, Slackware, etc...) it is perfectly fine
to use a standard Linux kernel from www.kernel.org. Simply put,
be aware that a standard Linux kernel may not offer features that
your distribution has incorporated into their version(s) of the
kernel. Check your distribution's documentation to verify. Those
that I know of that do patch their kernels (and this is *not* an
exhaustive list) are RedHat, Mandrake, and SuSE. I am sure that
there are many others.
In our next issue, we will take a look at configuring and building
the kernel, and setting up your machine to boot from it.
