Linux Solutions

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.