19 - Linux Modules

Modules are a very important part of the Linux operating system. Modules extend the functionality of the Linux kernel . Modules are special files that implement one or another functionality. Device drivers are also a type of module. Modules can be independent - self-sufficient to perform the functions inherent in them, and can be dependent on other modules.

The modules are located in the / lib / modules / kernel version directory. If you have several versions of the kernel installed, then, as a rule, the same number of directories will be located in the / lib / modules / directory. For example:

igor @ ubuntu: ~ / linux $ ls -1 / lib / modules /
2.6.31-14-generic
2.6.31-15-generic
2.6.31-16-generic

The modules interact very closely with the kernel, so for each revision of the kernel a subdirectory with the modules is generated. In boot scripts using the uname -r command, the kernel version is calculated and the modules are loaded from the directory with the appropriate name.

To view the list of loaded modules, com *** and lsmod is intended . A com *** and displays information in three columns: the name of the module, the size of the module and dependent modules. The third column indicates the modules whose operation depends on the module that is listed in the first column.

Module Size Used by
nfs_acl 2844 0
sunrpc 191712 1 nfs_acl
qnx4 8576 0

In the example we see that the operation of the nfs_acl module depends on the sunrpc module.

To load a module into RAM (and the kernel could use its functions), you can use the *** command at insmod . The *** command is being performed on behalf of the superuser and as the parameter you need to specify the name of the module file with the full path to the file:

igor @ ubuntu: ~ / linux $ sudo insmod /lib/modules/2.6.31-16-generic/kernel/fs/qnx4/qnx4.ko

The loadable module is responsible for the ability of the kernel to interact with the qnx file system. Check whether the module is loaded:

igor @ ubuntu: ~ / linux $ lsmod | grep qnx
qnx4 8576 0

Module loaded.

To unload the module from memory is designed com *** and rmmod . As a parameter, com *** and rmmod takes the name of the module in the form in which it gives it *** and a lsmod . When specifying the module name, you can use the TAB key to add a name by the first letters.

igor @ ubuntu: ~ / linux $ sudo rmmod qnx4
igor @ ubuntu: ~ / linux $ lsmod | grep qnx

If you try to unload a module from which other modules depend, we will get a warning about which modules use the module being unloaded, and the module will not be unloaded:

igor @ ubuntu: ~ / linux $ sudo rmmod sunrpc
ERROR: Module sunrpc is in use by nfs_acl

The com *** and insmod is a very simple com *** and not very user friendly, so the more advanced com *** and modprobe is most often used. To load a module using the modprobe command, you must pass the module name to it. For example:

igor @ ubuntu: ~ / linux $ sudo modprobe qnx4
igor @ ubuntu: ~ / linux $ lsmod | grep qnx
qnx4 8576 0

The main advantage of the modprobe command is that, unlike insmod, it can disassemble module dependencies. At the beginning I said that the modules may depend on other modules and if you try to com *** insmod load a module that depends on another module (and it is not loaded), you will get an error. For example:

igor @ ubuntu: ~ / linux $ sudo insmod /lib/modules/2.6.31-16-generic/kernel/fs/nfs_common/nfs_acl.ko
insmod: error inserting '/lib/modules/2.6.31-16-generic/kernel/fs/nfs_common/nfs_acl.ko': -1 Unknown symbol in module

A com *** and modprobe can use the file / lib / modules / kernel version / modules.dep which describes all the dependencies of the modules. If you open this file and find the line for the module nfs_acl.ko , you can see that it depends on the module sunrpc.ko . A com *** insmod in this case would have to be used twice: first to load the sunrpc.ko module, and then for the nfs_acl.ko module:

igor @ ubuntu: ~ / linux $ sudo insmod /lib/modules/2.6.31-16-generic/kernel/net/sunrpc/sunrpc.ko
igor @ ubuntu: ~ / linux $ sudo insmod /lib/modules/2.6.31-16-generic/kernel/fs/nfs_common/nfs_acl.ko

Com *** and modprobe itself resolves dependencies and loads the necessary modules:

igor @ ubuntu: ~ / linux $ sudo modprobe nfs_acl
igor @ ubuntu: ~ / linux $ lsmod
Module Size Used by
nfs_acl 2844 0
sunrpc 191712 1 nfs_acl

The file / lib / modules / kernel version / modules.dep is generated and updated by the com *** and depmod . A com *** and depmod looks at information about each module and generates dependencies that are written to the file / lib / modules / kernel version / modules.dep .

Another useful com *** and when working with modules is com *** and modinfo . modinfo - reads information about the module and displays it on the screen:

igor @ ubuntu: ~ / linux $ modinfo nfs_acl
filename: /lib/modules/2.6.31-16-generic/kernel/fs/nfs_common/nfs_acl.ko
license: GPL
srcversion: F7BFA9B63618825ED524789
depends: sunrpc
vermagic: 2.6.31-16-generic SMP mod_unload modversions 586

Among other things, we see information about the file name of the module (string filename), and dependencies (string depends).

An important point for understanding the operation of models is that the module during its loading can take parameters that can affect its operation. This topic is not an easy one and we will not discuss it in this lecture, but you need to know about it. What parameters can take the module can see com *** th modinfo . Not all modules can accept parameters (for example, our nfs_acl module does not have such parameters), but the example below shows the module to which parameters can be passed:

igor @ ubuntu: ~ / linux $ modinfo snd-bt87x
filename: /lib/modules/2.6.31-16-generic/kernel/sound/pci/snd-bt87x.ko
license: GPL
parm: index: Index value for Bt87x soundcard (array of int)
parm: id: id string for Bt87x soundcard (array of charp)
parm: enable: Enable Bt87x soundcard (array of bool)
parm: digital_rate: Bt87x soundcard (array of int) digital input rate
parm: load_all: Allow to load the non-whitelisted cards (bool)

Lines starting with parm are the parameter descriptions.

To transfer the parameters to the module (and not only), there is a file /etc/modprobe.conf , which the modprobe program looks at before launching and unloading the module and if certain additional actions are described for the module, they will be executed. In some distributions, the /etc/modprobe.conf file is missing, instead of it, a com *** and modprobe uses configuration files from the /etc/modprobe.d / directory. Read more about this file in the man modprobe.conf help.