Linux Solutions

Welcome to the tutorial guide. The guide will provide a user with guidance and information on .modinfo

An ELF object file consists of various named sections. Some of them are basic parts of an object file, for example the .text section contains executable code that a loader loads. If you want to make up any section you want and have it used by special programs, then you can. For the purposes of Linux LKMs, there is the .modinfo section. An LKM doesn’t have to have a section named .modinfo to work, but the macros that a user is supposed to use to code an LKM cause one to be generated, so they generally do.

If you would like to view the sections of an object file, including the .modinfo section if it exists, please use the objdump program.
-In order to see all the sections in the object file for the msdos LKM, please see following:
objdump msdos.o –section-headers

- in order to see the contents of the .modinfo section:
objdump msdos.o –full-contents –section=.modinfo

A user can use the modinfo program to interpret the contents of the .modinfo section.
Please note that insmod uses the .modinfo section for the following:
• It contains the kernel release number for which the module was built. I.e. of the kernel source tree whose header files were used in compiling the module.
insmod uses that information as explained in Section 6.
• It describes the form of the LKM’s parameters. insmod uses this information to format the parameters you supply on the insmod command line into data structure initial values, which insmod inserts into the LKM as it loads it.
If you followed guidance and advise as provided in this tutorial guide then you would have learnt about .modinfo.

Welcome to the tutorial guide. The tutorial will provide guidance and instructions on technical details.

Please note that insmod makes an init_module system call to load the LKM into kernel memory. Loading it is the easy part. The init_module system call invokes the LKM’s initialisation routine right after it loads the LKM. insmod passes to init_module the address of the subroutine in the LKM named init_module as its initialisation routine.

(This is confusing — every LKM has a subroutine named init_module, and the base kernel has a system call by that same name, which is accessible via a subroutine in the standard C library also named init_module).

The LKM author set up init_module to call a kernel function that registers the subroutines that the LKM contains. For example, a character device driver’s init_module subroutine might call the kernel’s register_chrdev subroutine, passing the major and minor number of the device it intends to drive and the address of its own “open” routine among the arguments. register_chrdev records in base kernel tables that when the kernel wants to open that particular device, it should call the open routine in our LKM.

But the astute reader will now ask how the LKM’s init_module subroutine knew the address of the base kernel’s register_chrdev subroutine. This is not a system call, but an ordinary subroutine bound into the base kernel. Calling it means branching to its address.

In Linux2.4, insmod does the relocation and passes a fully linked module image, ready to stuff into kernel memory, to the kernel. The description below covers the 2.4 case.
insmod functions as a relocating linker/loader. The LKM object file contains an external reference to the symbol register_chrdev. insmod does a query_module system call to find out the addresses of various symbols that the existing kernel exports. register_chrdev is among these. query_module returns the address for which register_chrdev stands and insmod patches that into the LKM where the LKM refers to register_chrdev.
If you want to see the kind of information insmod can get from a query_module system call, look at the contents of /proc/ksyms.
Note that some LKMs call subroutines in other LKMs. They can do this because of the __ksymtab and .kstrtab sections in the LKM object files. These sections together list the external symbols within the LKM object file that are supposed to be accessible by other LKMs inserted in the future. insmod looks at __ksymtab and .kstrtab and tells the kernel to add those symbols to its exported kernel symbols table.

If you would like to see this then please insert the LKM msdos.o and then you will notice in /proc/ksyms the symbol fat_add_cluster. Any subsequently inserted LKM can branch to fat_add_cluster, and in fact msdos.o does just that.

If you followed the guidance and instructions as provided in this tutorial guide then you would have learnt about technical details.

Welcome to the tutorial guide. The guide will provide a user with guidance and instructions on module parameters.

It is useful to compare parameters that get passed to LKMs and parameters that get passed to modules that are bound into the base kernel, especially since modules often can be run either way.

Parameters can be passed to an LKM by specifying following io=0×300 on the insmod command. If a module is bound into the base kernel, a user can pass parameters to it via the kernel boot parameters. There are ways to specify kernel boot parameters.
-A common way to specify kernel boot parameters is at a lilo boot prompt.
-another way is with an append statement in the lilo configuration file.

The kernel initialises an LKM at the time a user loads it. It initialises a bound-in module at boot time. As there is only one string of kernel boot parameters, a user will need some way within that string to identify which parameters go to which modules. The rule for this is that if there is a module named abc, then a kernel boot parameter named abc is for that module. The value of a kernel boot parameter is an arbitrary string that makes sense only to the module.

Sometimes a user will note that LKMs’ parameter is its own name. for example, if a user loads the Mitsumi CDROM driver with a command like

insmod mcd mcd=0×340

It will have the parameter named mcd instead of, io, but this is done for consistency with the case where a user binds mcd into the base kernel, in which case the user would select the I/O port address with the characters mcd=0×340 in the kernel boot parameters.

If you followed advise and guidance as provided in this tutorial guide then you would have learnt about module parameters.

Welcome to the tutorial guide. The guide will provide a user with guidance and instructions on how to to boot without a disk device driver.

Please note that for most systems, the ATA disk device driver must be bound into the base kernel because the root filesystem is on an ATA disk and the kernel cannot mount the root filesystem, much less read any LKMs from it, without the ATA disk driver. If you want the device driver for the root filesystem to be an LKM, then this can be done with Initrd:

Let’s see what is Initrd. Initrd is the name of the initial ramdisk feature of Linux. With this, you have your loader load a filesystem into memory (as a ramdisk) before starting the kernel. When it starts the kernel, it tells it to mount the ramdisk as the root filesystem. A user can put the disk device driver for the real root filesystem and all the software that is required is to load it in that ramdisk filesystem. The startup programs (which live in the ramdisk) eventually mount the real (disk) filesystem as the root filesystem. It is good to know that a ramdisk doesn’t require any device driver.

If you followed advise and guidance as provided in this tutorial guide then you would have learnt about booting without a disk device driver.

Welcome to the tutorial guide. The guide will provide a user with advise and guidance on how to SMP symbols and licensing.

The symbol version prefix contains smp if the symbol is defined in or referenced by code that was built for symmetric multiprocessing (SMP) machines. It means that it was built for use on a system that has more than one CPU. A user can choose whether to build in SMP capability or not via the Linux kernel configuration process to wit with the CONFIG_SMP configuration option.

If a user is planning to use symbol versioning then he/she will get unresolved symbols if the base kernel was built with SMP capability and the LKM that he/she is inserting was not, or vice versa.

Please note that there is generally no reason to omit SMP capability from a kernel, even if a user has only one CPU. Just because the capability is there doesn’t mean that a user should have multiple CPUs. However, there are some machines on which the SMP-capable kernel will not boot because it reaches the conclusion that there are zero CPUs

As the copyright owners of some kernel code license their programs to the public to make and use copies so the license may say that you may only call your copy of the program from a program which is similarly licensed to the public.

According to some interpretations, the license says if you make a copy of Shafkat’s LKM, you can’t allow Shahzad’s LKM to call its compression subroutines if Shahzad’s does not supply his source code to the world too. The idea is to encourage Shahzad to open up his source code.

If you would like to support and enforce such a license, the licensor can cause his program to export symbols under a special name that is the real name of the symbol plus the prefix “GPLONLY”. A naive loader of a client LKM would not be able to resolve those symbols. For example: Shafkat’s LKM provides the service ShafkatssService() and declares it to be a GPL symbol. The LKM consequently exports ShafkatsService() under the name GPLONLY_shafkatsService. If Shahzad’s LKM refers to ShafkatsService, the naive loader will not be able to find it, so will fail to load Shahzad’s LKM.

However, a modern version of insmod knows to check for GPLONLY_shafkatsService if it can’t find shafkatsService. But the modern insmod will refuse to do so unless Shahzad’s LKM declares that it is licensed to the public under GPL.

The purpose of this appears to be to prevent anyone from accidentally violating a license (or from credibly claiming that he accidentally violated the license). It is not difficult to circumvent the restriction if you want to. If you see this failure, it is probably because you’re using an old loader (insmode) that doesn’t know about GPLONLY.
The only other cause would be that the LKM author wrote the source code in such a way that it will never load into any Linux kernel, so there would be no point in the author distributing it.

If you followed advise and guidance as provided in this tutorial guide then you would have learnt about SMP symbols and licensing issues.

Welcome to the tutorial guide. The guide will provide a user with guidance and instructions on how to run multiple Kernels.

A user needs to ensure that the LKMs built for Kernel A get inserted when he/she boots Kernel A and the LKMs built for Kernel B gets inserted when he/she boots Kernel B.

It is a good idea to keep both kernels (old and new) on the system until the new Kernel starts working.

The most common way to do this is with the LKM-hunting feature of modprobe. modprobe understands the conventional LKM file organization and loads LKMs from the appropriate subdirectory depending on the kernel that is running.

A user can set the uname release value, which is the name of the subdirectory in which modprobe looks, by editing the main kernel makefile when a user build the kernel and setting the VERSION, PATCHLEVEL, SUBLEVEL, and EXTRAVERSION variables at the top.

If you followed the advise and instructions as provided in this tutorial guide then you would have learnt about running multiple Kernels.

Welcolme to the tutorial guide. The guide will provide a user with guidance and instructions on how to locate the LKM files on the system.

As the LKM world is flexible enough which means that the files that are required to loaded can live anywhere on the system. There is also a convention that most systems follow: The LKM .o files are in the directory /lib/modules, divided into subdirectories. Please note that there is one subdirectory for each version of the kernel, since LKMs are specific to a kernel. Each subdirectory contains a complete set of LKMs.

The subdirectory name is the value that a user can get from the uname –release command.
When you build Linux, a standard make modules and make modules_install should install all the LKMs that are part of Linux in the proper release subdirectory.

If you build a lot of kernels then you can keep the LKMs together with the base kernel and other kernel-related files in a subdirectory of /boot. The only drawback of this is that a user cannot have /boot reside on a tiny disk partition. In some systems, /boot is on a special tiny boot partition and contains only enough files to get the system up to the point that it can mount other filesystems.

If you followed the guide then you would have learnt about locating the LKMs.

Welcome to the tutorial guide. The guide will provide a user with advise and guidance on how to view proc/modules.

In order to see the presently loaded LKMs, please run following code:

cat /proc/modules

You will view a line similar to mentioned below:

serial 28204 0

In order to fully understand this, please note that
-the left column is the name of the LKM, which is normally the name of the object file from which you loaded it, minus the “.o” suffix.
-The “28204″ is the size in bytes of the LKM in memory.
-The “0″ is the use count and it tells how many things presently depend on the LKM being loaded. Typical

Please note that the LKM maintains this count, but the module manager uses it to decide whether to permit an unload. There is an exception to the above description of the use count. You may see -1 in the use count column. -1 means that this LKM does not use counts to determine when it is OK to unload. Instead, the LKM has registered a subroutine that the module manager can call that will return an indication of whether or not it is OK to unload the LKM.

Let’s have a look at another example:

lp 5280 2 (unused)
parport_pc 7552 1
parport 7600 3 [lp parport_pc]

In the example, you will see that there is a number 3 there and there is some text in square brackets. The information or text in square brackets describes dependencies. The information in brackets is modules and modules lp and parport_pc refer to addresses within module parport (via external symbols that parport exports). So lp and parport_pc are “dependent” on (and are “dependencies of”) parport.

It is also good to know that a user cannot unload an LKM that has dependencies, though the dependencies can be removed by unloading the dependent LKMs.

The “(unused)” legend means the LKM has never been used, i.e. it has never been in a state where it could not be unloaded. The kernel tracks this information for one simple reason: to assist in automatic LKM unloading policy. In a system where LKMs are loaded and unloaded automatically, you don’t want to automatically load an LKM and then, before the person who needed it loaded has a chance to use it, unload it because it is not in use.
Let’s have a look at LKM which is in a deleted state. It is as provided below:

mydriver 8154 0 (deleted)

The LKM as mentioned in the example is in a deleted state and it means is that the LKM is in the process of being unloaded. You can no longer load LKMs that depend on it, but it’s still present in the system. Unloading an LKM is usually close to instantaneous, so if you see this status, you probably have a broken LKM. Its cleanup routine probably got into an infinite loop or stall or crashed. The only way to clear this is to do a reboot.

If you followed advise and guidance as provide in this tutorial guide then you would have successfully learnt about LKM proc/modules.

Welcome to the tutorial guide. The guide will provide a user with advise and guidance on how to carry out automatic loading and unloading for the kernel.
Automatic Loading
Let’s have a look at automatic loading. You can cause an LKM to be loaded automatically when the kernel first needs it. This can be done by either the kernel module loader, which is part of the Linux kernel, or the older version of it, a kerneld daemon.

As an example, let’s say you run a program that executes an open system call for a file in an MS-DOS filesystem. But you don’t have a filesystem driver for the MS-DOS filesystem either bound into your base kernel or loaded as an LKM. So the kernel does not know how to access the file you’re opening on the disk.

The kernel recognises that it has no filesystem driver for MS-DOS, but that one of the two automatic module loading facilities are available and uses it to cause the LKM to be loaded. The kernel then proceeds with the open.

Please note that automatic kernel module loading is not worth the complexity in most modern systems. It may make sense in a very small memory system, because you can keep parts of the kernel in memory only when you need them. But the amount of memory these modules uses is so cheap today that you will normally be a lot better off just loading all the modules you might need via startup scripts and leaving them loaded.

Red Hat Linux uses automatic module loading via the kernel module loader and the kernel module loader and kerneld use modprobe, ergo insmod, to insert LKMs.

- Kernel Module Loader
There is some documentation of the kernel module loader in the file Documentation/kmod.txt in the Linux 2.4 source tree. This section is more complete and accurate than that file. You can also look at its source code in kernel/kmod.c.
The kernel module loader is an optional part of the Linux kernel. You get it if you select the CONFIG_KMOD feature when you configure the kernel at build time.
When a kernel that has the kernel module loader needs an LKM, it creates a user process (owned by the superuser, though) that executes modprobe to load the LKM, then exits. By default, it finds modprobe as /sbin/modprobe, but you can set up any program you like as modprobe by writing its file name to /proc/sys/kernel/modprobe. For example:
# echo “sbin/mymodprobe” >/proc/sys/kernel/modprobe
The kernel module loader passes the following arguments to the modprobe: Argument Zero is the full file name of modprobe. The regular arguments are -s, -k, and the name of the LKM that the kernel wants. -s is the user-hostile form of –syslog; -k is the cryptic way to say –autoclean. I.e. messages from modprobe will go to syslog and the loaded LKM will have the “autoclean” flag set.
The most important part of the modprobe invocation is, of course, the module name. Note that the “module name” argument to modprobe is not necessarily a real module name. It is often a symbolic name representing the role that module plays and you use an alias statement in modules.conf to tell what LKM gets loaded. For example, if your Ethernet adapter requires the 3c59x LKM, you would have probably need the line
alias eth0 3c59x
in /etc/modules.conf. Here is what the kernel module loader uses for a module name in some of the more popular cases (there are about 20 cases in which the kernel calls on the kernel module loader to load a module):
• When you try access a device and no device driver has registered to serve that device’s major number, the kernel requests the module by the name block-major-N or char-major-N where N is the major number in decimal without leading zeroes.
• When you try to access a network interface (maybe by running ifconfig against it) and no network device driver has registered to serve an interface by that name, the kernel requests the module named the same as the interface name (e.g. eth0). This applies to drivers for non-physical interfaces such as ppp0 as well.
• When you try to access a socket in a protocol family which no protocol driver has registered to drive, the kernel requests the module named net-pf-N, where N is the protocol family number (in decimal without leading zeroes).
• When you try to NFS export a directory or otherwise access the NFS server via the NFS system call, the kernel requests the module named nfsd.
• The ATA device driver (named ide) loads the relevant drivers for classes of ATA devices by the names: ide-disk, ide-cd, ide-floppy, ide-tape, and ide-scsi.
The kernel module loader runs modprobe with the following environment variables (only): HOME=/; TERM=linux; PATH=/sbin:/usr/sbin:/bin:/usr/bin.
The kernel module loader was new in Linux 2.2 and was designed to take the place of kerneld. It does not, however, have all the features of kerneld.
In Linux 2.2, the kernel module loader creates the above mentioned process directly. In Linux 2.4, the kernel module loader submits the module loading work to Keventd and it runs as a child process of Keventd.
The kernel module loader is a pretty strange beast. It violates layering as Unix programmers generally understand it and consequently is inflexible, hard to understand, and not robust. Many system designers would bristle just at the fact that it has the PATH hardcoded. You may prefer to use kerneld instead, or not bother with automatic loading of LKMs at all.
- Kerneld
kerneld is a user process, which runs the kerneld program from the modutils package. kerneld sets up an IPC message channel with the kernel. When the kernel needs an LKM, it sends a message on that channel to kerneld and kerneld runs modprobe to load the LKM, then sends a message back to the kernel to say that it is done.
- Automatic Unloading - Autoclean
This will show a user about how to automatically unload (autoclean) the kernel.
Please note that each loaded LKM has an autoclean flag which can be set or unset. A user can control this flag with parameters to the init_module system call. If you do that through insmod, you use the –autoclean option.
You can see the state of the autoclean flag in /proc/modules. Any LKM that has the flag set has the legend autoclean next to it.

As we know that the purpose of the autoclean flag is to let a user automatically remove LKMs that haven’t been used in a while. So by using automatic module loading and unloading, a user can keep loaded only parts of the kernel that are presently needed, and can save memory.

There is a form of the delete_module system call that says, “remove all LKMs that have the autoclean flag set and haven’t been used in a while.” Kerneld typically calls this once per minute. You can call it explicitly with an rmmod –all command.
As the kernel module loader does not do any removing of LKMs, if you use that you might want to have a cron job that does a rmmod –all periodically.

If you followed advise and guidance as provided in the tutorial guide then you would have learnt about automatic and non-automatic kernel module loading.

Welcome to the tutorial guide. The guide will provide a user with advise and guidance on intelligent loading.

After you have module loading and unloading figured out using insmod and rmmod, you can let the system do more of the work for you by using the higher level program modprobe. See the modprobe man page for details.

The main thing that modprobe does is automatically load the prerequisites of an LKM you request. It does this with the help of a file that you create with depmod and keep on your system.
The following performs an insmod of msdos.o, but before that does an insmod of fat.o, since you have to have fat.o loaded before you can load msdos.o.

modprobe msdos

This major thing that modprobe does is to find the object module containing the LKM given just the name of the LKM.

The modprobe msdos might load /lib/2.4.2-2/fs/msdos.o.

The modprobe eth0 loads the appropriate network device driver to create and drive the eth0 device, assuming you set that up properly in modules.conf.
modprobe is especially important because it is by default the program that the kernel module loader uses to load an LKM on demand. Please note that if you use automatic module loading, you will need to set up modules.conf properly or things will not work.

The depmod scans the LKM object files (typically all the .o files in the appropriate /lib/modules subdirectory) and figures out which LKMs prerequire (refer to symbols in) other LKMs. It generates a dependency file (typically named modules.dep), which you normally keep in /lib/modules for use by modprobe.

modprobe can be used to remove stacks of LKMs.
Via the LKM configuration file (typically /etc/modules.conf), you can fine tune the dependencies and do other fancy things to control LKM selections. And you can specify programs to run when you insert and remove LKMs, for example to initialize a device driver.
If you are maintaining one system and memory is not in short supply, it is probably easier to avoid modprobe and the various files and directories it needs, and just do raw insmods in a startup script.

If you followed the advise and guidance as provide in this tutorial guide then you would have learnt about intelligent loading.