One thing that deserves mention in this section is the variety of Linux versions that
exist in the world and what we call them. Unlike a proprietary software product where
one company carefully controls the name and creates a small number of well defined
releases, variations of Linux are developed by lots of different independent people and all of them are called Linux.
The most basic Linux releases are controlled by Linux Torvalds and distributed by
kernel.org as the main Linux releases. They are the only releases that can properly by
called “Linux 2.4”,” Linux 2.6”,etc.
But hardly anybody uses those releases. Instead, people start with those releases and
make modifications. People often sloppily refer to a Linux based on Linux 2.6.6 as
Linux 2.6.6 itself. But to be correct, you have to add something - usually a hyphen
and a suffix. Red Hat versions of Linux, which you see a lot, unfortunately use just a
plain number for that suffix, for example 2.6.6-12.
Remember that in this document Linux means the kernel. When we consider the operating
systems called Linux, the situation gets even more complicated.
2.4 to 2.6
LKM
The biggest change to LKMs between Linux 2.4 and 2.6 is an internal one: LKMs get
loaded much differently. Most people won’t see any difference except that the suffix
on a file containing an LKMs has changed, because they use high level tools to manage
the LKMs and the interface to those tools hasn’t changed.
Before Linux 2.6, a user space program would interpret the ELF object (.0) file and do
all the work of linking it to the running kernel, generating a finished binary image.
The program would pass that image to the kernel and the kernel would do little more
than stick it in memory. In Linux 2.6, the kernel does the linking. A user space
program passes the contents of the ELF object file directly to the kernel. For this to
work, the ELF object image must contain additional information. To identify this
particular kind of ELF object file, we name the file with suffix “.ko” (kernel
object) instead of “.o” for example, the serial device driver that in Linux 2.4 lived in the file serial.o in Linux 2.6 lives in the file serial.ko.
So there is a whole new module package for use with Linux 2.6. In it, insmod is a
trivial program, as compared to the full blown linker of the Linux 2.4 version.
Also, the procedure to build an LKM is somewhat harder. To make a .ko file, you start
with a regular .o file. You run the program modpost on it to create a C source file
that describes the additional sections the .ko file needs. We’ll call this the .mod
file because you conventionally include “.mod” in the file name.
You compile the .mod file and link the result with the original .o file to make a .ko
file.
The .mod object file contains the name that the LKM instance will have when you load
the LKM. You set that name with a -D compile option (when you compile the .mod file)
that sets the KBUILD_MODNAME macro.
This change means some things are decidedly harder - choosing the name for the LKM
instance, for example. In Linux 2.4, the name was one of the inputs to the kernel.
Insmod decided on the name and passed it to the kernel. Insmod’s -o option told it
explicitly what to use for the LKM instance name. But in 2.6, there is no such
parameter on the system call and hence no -o option on insmod. The name is part of
the ELF object (.o file) that you pass to the kernel. The default name is built into
the ELF object, but if you want to load it with some other name, you must edit the ELF
image before passing it to insmod.
