One thing that deserves mention in this section is the variety ofLinux versions that exist in the world and what we call them. Unlikea proprietary software product where one company carefully controlsthe name and creates a small number of well defined releases,variations of Linux are developed by lots of different independentpeople and all of them are called Linux.
The most basic Linux releases are controlled by Linus Torvalds anddistributed by kernel.org as the main Linux releases. They are theonly releases that can properly by called "Linux 2.4," "Linux 2.6.6,"etc.
But hardly anybody uses those releases. Instead, people start withthose releases and make modifications. People often sloppily refer toa Linux based on Linux 2.6.6 as Linux 2.6.6 itself. But to becorrect, you have to add something -- usually a hyphen and a suffix.Red Hat versions of Linux, which you see a lot, unfortunately use justa plain number for that suffix, e.g. Linux 2.6.6-12. (It would bebetter if they used something more explicitly Red Hat, such as Linux2.6.6-rh12).
Remember that in this document, "Linux" means the kernel;when we consider the operating systems called "Linux", thesituation gets even more complicated.
The biggest change to LKMs between Linux 2.4 and Linux 2.6 is aninternal one: LKMs get loaded much differently. Most peoplewon't see any difference except that the suffix on a file containingan LKM has changed, because they use high level tools to managethe LKMs and the interface to those tools hasn't changed.
Before Linux 2.6, a user space program would interpret the ELF object(.o) file and do all the work of linking it to the running kernel,generating a finished binary image. The program would pass that imageto the kernel and the kernel would do little more than stick it inmemory. In Linux 2.6, the kernel does the linking. A user spaceprogram passes the contents of the ELF object file directly to thekernel. For this to work, the ELF object image must containadditional information. To identify this particular kind of ELFobject 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 fileserial.o in Linux 2.6 lives in the fileserial.ko.
So there is a whole new modutils packagefor use with Linux 2.6. In it, insmod is a trivialprogram, as compared to the full blown linker of the Linux 2.4version.
Also, the procedure to build an LKM is somewhat harder. To make a .kofile, you start with a regular .o file. You run the program modpost (which comes with the Linux source code) on it tocreate a C source file that describes the additional sections the .kofile needs. We'll call this the .mod file because you conventionallyinclude ".mod" in the file name.
You compile the .mod file and link the result with the original .ofile to make a .ko file.
The .mod object file contains the name that the LKM instance will havewhen 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 forthe LKM instance, for example. In Linux 2.4, the name was one of theinputs to the kernel. insmod decided on the nameand passed it to the kernel. insmod's -o optiontold 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 optionon insmod. The name is part of the ELF object (.ofile) that you pass to the kernel. The default name is built into theELF object, but if you want to load it with some other name, you mustedit the ELF image before passing it to insmod.