Introduction to Linux Kernel Modules.3

Start article >>

Start article 2 >>

When the linux kernel discovers the need for a module, the kernel request to the kernel daemon ( kerneld) to load the appropriate module. Let’s take an example: we are going to mount a NTFS partition in the Linux system. If the NTFS filesystem support is not statically implemented in the kernel (but compiled as a module), the kernel daemon will search for the appropriate module and load it from the repository. Then the parition is mounted for the use. Let’s go into deep of the action of the kernel daemon (kerneld). The kerneld is the normal user process having the th exclusive superuser privileges. At the time of the booting, kerneld open the IPC channel to the kernel and uses it for transfering messages (request for loading modules) to and from the kernel.

While loading the loading the module, the kerneld calls modprobe and insmod to load the required module. The insmod utility should able to access the requested module. The demand loadable kernel modules are usually located at the /lib/module/ directory as the object files linked as relocatable images . Let us now revisit the working of the insmod to get the clear picture of the module loading operation. We have already seen that the insmod is used to laod module to the kernel. The insmod depends on some the critical system calls to load the module to the kernel. The insmod uses the sys_create_module to allocate kernel memory to hold module. insmod uses get_kernel_syms system call to get the kernel symbol table inorder to link the module.

Then it calls sys_init_module system call to copy the relocatable object code of the module to the kernel space. And soon after this, insmod calls the initialization function of the concerned module i.e. init_module . All of these system calls can be found in kernel/module.c. Unloading Modules:The modules can be unloaded using rmmod command. While removing modules, rmmod ensures the restriction that the modules are not in use and they are not referred by any other module or the part of the kernel. The demand loaded modules (ie. the modules loaded by kerneld) are automatically removed from the system by kerneld when they are no longer used.

Every time it’s idle timer expires, kerneld makes a system call requesting for all the demand loaded kernels which are not busy state should be removed. The modules whose visited flags are cleared and marked as AUTOCLEAN , are unloaded. Asuming that the module can be unloaded, the cleanup_module function of the concerned module is called to freeup the kernel resources it has allocated. After the successful execution of the cleanup_module, the module datastructure is marked DELETED and it is unlinked from the kernel and is unlisted from the list of kernel modules. All the reference list of the modules on which it (module removed) is dependent are mofied and dependency is released. All the kernel momory allocated to the concerned module are deallocated and returned to the kernel memory spool.

Version Dependency of Modules: The version dependency of the module is one of the most tricky part of the Linux Kernel Module programming. Typically, the modules are requred to be compiled for each version of the kernel. Each module defines a symbol called kernel_version, which insmod matches against the version number of the current kernel. The current kernel 2.2.x/2.4.x define the symbol in . Hence if the module is made up of multiple source files, the should be included only one of the source files. Though typically, modules should be recompiled for each kernel version, it is not always possible to recompile module when it is run on as a commercial module distributed in binary form.

The kernel developers has provided a flexible way to deal with the version problem. The idea is that a module is incompatible with a different kernel version, only if the software interface offered by the kernel is changed. The software interface is represented by the function prototype and the exact definition of all the data structures involved in the function call. The CRC algorithm can be used to map all the information about software interface to the single 32bit number.

The issue of version dependency is handled by using the name of the each symbol exported. ConclusionIn the above sections, I have discussed the simple most life cycle of the module. For going deeper, please refer to the book by Rubini which I have mentioned in the begining of this article. It is also nice to look at the kernel code to refer to the system-calls which are responsible for module loading or unloading. I do hope that I will cover some more on Module-Programming in the future articles (provided, I have the time to do some writting in the wee hours).

“Best Custom Writing Services” is the service where one can get to know the survey of the best writing services accessible in these times. To give an order is a simple operation, but to select good custom writing services is positively a tall order to fill. You can find out all significant information about custom writing service in our site. We are happy to help you with your choice!

Leave a Reply

You must be logged in to post a comment.