Common module operation commands for Linux-driven learning

1, the Common Module operation command

(1) Lsmod (list module, display of modules), function is to print out the list of modules installed in the current kernel

(2) Insmod (Install module), the function is to install a module to the current kernel, the usage is Insmod Xxx.ko

(3) Modinfo (module information, modules information), function is to print out a kernel module of the self-brought information. , usage is modinfo Xxx.ko, note to add. Ko, that is, a static file form.

(4) Rmmod (remove module, unload modules), the function is to uninstall an installed module from the current kernel, the usage is rmmod xxx.ko rmmod xxx can

(5) The rest of the back, and temporarily do not use (such as modprobe, DEPMOD, etc.)

2, the installation of the module

(1) Insmod and MODULE_INIT macro. The module source code uses the MODULE_INIT macro to declare a function (in our case, the Chrdev_init function), the function is to specify Chrdev_init this function and insmod command binding

Up, that is to say, when we insmod Module_test.ko, the actual operation of the Insmod command is to help us invoke the Chrdev_init function.

(3) Module installation INSMOD In addition to help us call the Module_init macro declared function, actually did something else (such as lsmod can see a module is also insmod help us in the internal record, that is

Add our modules to a data structure in the kernel), but we don't have to worry about it.

3, the unloading of the module

(1) Correspondence between Module_exit and Rmmod

When we execute the rmmod command, we execute the function of the module's Module_exit macro declaration, and we will also remove the module information from the data structure managed by our kernel's module.

4, the version of the module information

(1) Use Modinfo to view the version information of the module

(2) There is also a certain version information in the kernel zimage

(3) Insmod when the module vermagic must be the same as the kernel, otherwise, can not install, error message is: Insmod:ERROR:could not insert module MODULE_TEST.KO:INVALID module format

(4) The version information of the module is to ensure the compatibility of the module and the kernel, is a security measure

(5) How to ensure that the vermagic of the module and the vermagic of the kernel are consistent? The kernel source tree of the compiled module is the kernel source tree in which we compile the running kernel. To be blunt is the module and the kernel to the same door.

5. Common macros in Modules

(1) Module_license ("GPL"), the license of the module. Generally stated as GPL licenses, and preferably not less, there may be inexplicable errors (such as some obvious function promotion cannot be found).

(2) Module_author ("Tao Deng <> [email protected]"), which is used to add the author information of the module

(3) Module_description ("xxx"), which is used to add the description information of the module

(4) Module_alias ("xxxx"), which is used to add the alias of the module

Above these things we can see through the modinfo command when viewing the module

6. Function modifier

(1) __init, is essentially a macro definition, in the kernel source code has a # define __init xxxx. The function of this __init is to put the functions he modifies into the. Init.text segment (the function is by default

Into the. Text field). The essence is the use of attribute in C advanced.

All such functions in the entire kernel are placed in the. Init.text segment, so all the kernel modules ' __init-modified functions are actually unified. The kernel will load when it starts. Init.text

section of the module installation function, after loading will be released to save memory.

(2) __exit

7, PRINTK function detailed

(1) Printk the function used to print information in the kernel source code, the usage is very similar to printf.

(2) The biggest difference between PRINTK and printf: printf is a C library function that is used in application-level programming and cannot be used in the Linux kernel source code; PRINTK is a printing function that is encapsulated in the source code of the Linux kernel.

is a kernel source of a common function, can only be used within the scope of the kernel source code, can not be used in application programming.

(3) PRINTK more than printf: print-level settings. The print level of the PRINTK is used to control whether the information printed by PRINTK is displayed on the terminal. Debug information in the application is either open or

Close all, generally implemented with conditional compilation (debug macro), but in the kernel, because the kernel is very large, printing information is very much, sometimes the whole debugging kernel when the printing of information is too much to find it or not.

The method of debugging. So there is the concept of print level.

(4) The command line of the operating system also has a print information level attribute with a value of 0-7. When executing PRINTK in the current operating system, I compare the print level in PRINTK with the print levels set in my command line, less than my

Command-line set-level information will be released to print out, greater than is intercepted. For example, my Ubuntu print level default is 4, then the PRINTK set in the level than 4 can be printed out, than the 4 is not printed out.

Can be viewed by this command: CAT/PROC/SYS/KERNEL/PRINTK

(5) This PRINTK print level control in Ubuntu is not practical, Ubuntu no matter how you set the level can not print directly, you must DMESG command to check.

8, about the driver module in the header file

(1) It is not the same thing to drive the header files contained in the source code and the header files contained in the original application programming program. The header file included in the application programming is the header file of the application layer, which is brought by the application compiler (such as the header file path of GCC

/usr/include, these things are not related to the operating system). Drive source is part of the kernel source code, the driver source of the header file is actually the kernel source directory under the Include directory of the header file.

9, using the Development Board to debug the module

(1) Set Bootcmd to enable the Development Board to download its own established kernel source tree compiled by tftp zimage:set bootcmd ' tftp 0x30008000 zimage;bootm 0x30008000 '

(2) Set Bootargs to mount the Board from NFS Rootfs (the kernel configuration requires it to support mounting NFS file systems, as this has been said in Uboot)

setenv Bootargs Root=/dev/nfs Nfsroot=192.168.1.141:/root/porting_x210/rootfs/rootfs ip= 192.168.1.10:192.168.1.141:192.168.1.1:255.255.255.0::eth0:off INIT=/LINUXRC console=ttySAC2,115200

(3) Modify the Kern_dir in the makefile to point to the kernel source tree that you set up

(4) Put your own compiled driver. ko file into the NFS shared directory

(5) Use Insmod, Rmmod, Lsmod and so on to carry out module experiment after the development Board is started.

Reference: "Zhu Youpeng embedded Linux Development \5.linux Driver Development \5.2. Character Device driver Basics"

Common module operation commands for Linux-driven learning