1.2. How Do Modules Get Into The Kernel?
You can see what modules are already loaded into the kernel by running lsmod, which gets its
information by reading the file /proc/modules.
How do these modules find their way into the kernel? When the kernel needs a feature that is not resident in the
kernel, the kernel module daemon kmod execs modprobe to load the module in. modprobe is passed a string in one of two forms:
If modprobe is handed a generic identifier, it first looks for that string in the file
/etc/modprobe.conf.
If it finds an alias line like:
alias char-major-10-30 softdog
|
it knows that the generic identifier refers to the module softdog.ko.
Next, modprobe looks through the file /lib/modules/version/modules.dep, to see if other modules
must be loaded before the requested module may be loaded. This file is created by depmod -a and
contains module dependencies. For example, msdos.ko requires the fat.ko module
to be already loaded into the kernel. The requested module has a dependancy on another module if the other module defines
symbols (variables or functions) that the requested module uses.
Lastly, modprobe uses insmod to first load any prerequisite modules into the kernel, and then the requested module.
modprobe directs insmod to /lib/modules/version/, the standard directory for modules. insmod is
intended to be fairly dumb about the location of modules, whereas modprobe is aware of the default location of modules,
knows how to figure out the dependancies and load the modules in the right order.
So for example, if you wanted to load the msdos module, you'd have to either run:
insmod /lib/modules/2.6.11/kernel/fs/fat/fat.ko
insmod /lib/modules/2.6.11/kernel/fs/msdos/msdos.ko
|
or:
What we've seen here is: insmod requires you to pass it full pathname and to insert the modules
in the right order, while modprobe just takes the name, without any extension, and figures out
all it needs to know by parsing /lib/modules/version/modules.dep.
Linux distros provide modprobe, insmod and depmod as a package called module-init-tools. In previous versions
that package was called modutils. Some distros also set up some wrappers that allow both packages to be installed
parallel and do the right thing in order to be able to deal with 2.4 and 2.6 kernels. Users should not need to care
about the details, as long as they're running recent versions of that tools.
Now you know how modules get into the kernel. There's a bit more to the story if you want to write your own modules
which depend on other modules (we calling this `stacking modules'). But this will have to wait for a future chapter.
We have a lot to cover before addressing this relatively high-level issue.
1.2.1. Before We Begin
Before we delve into code, there are a few issues we need to cover. Everyone's system is different and everyone has
their own groove. Getting your first "hello world" program to compile and load correctly can sometimes be a trick. Rest
assured, after you get over the initial hurdle of doing it for the first time, it will be smooth sailing
thereafter.
1.2.1.1. Modversioning
A module compiled for one kernel won't load if you boot a different kernel unless you enable
CONFIG_MODVERSIONS in the kernel. We won't go into module versioning until later in this guide.
Until we cover modversions, the examples in the guide may not work if you're running a kernel with modversioning
turned on. However, most stock Linux distro kernels come with it turned on. If you're having trouble loading the
modules because of versioning errors, compile a kernel with modversioning turned off.
1.2.1.2. Using X
It is highly recommended that you type in, compile and load all the examples this guide discusses. It's also
highly recommended you do this from a console. You should not be working on this stuff in X.
Modules can't print to the screen like printf() can, but they can log information and
warnings, which ends up being printed on your screen, but only on a console. If you insmod a module from an xterm,
the information and warnings will be logged, but only to your log files. You won't see it unless you look through
your log files. To have immediate access to this information, do all your work from console.
1.2.1.3. Compiling Issues and Kernel Version
Very often, Linux distros will distribute kernel source that has been patched in various non-standard ways,
which may cause trouble.
A more common problem is that some Linux distros distribute incomplete kernel headers. You'll need to compile
your code using various header files from the Linux kernel. Murphy's Law states that the headers that are missing are
exactly the ones that you'll need for your module work.
To avoid these two problems, I highly recommend that you download, compile and boot into a fresh, stock Linux
kernel which can be downloaded from any of the Linux kernel mirror sites. See the Linux Kernel HOWTO for more
details.
Ironically, this can also cause a problem. By default, gcc on your system may look for the kernel headers in
their default location rather than where you installed the new copy of the kernel (usually in /usr/src/. This can be fixed by using gcc's -I switch.
