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 dependency 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
dependencies 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 the 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 in 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 those 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 the 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.
