Linux Module Programming framework

Linux Module Programming framework

Linux is a single-core system, the peripheral devices of the universal computing platform are frequently changed, it is not possible to all (including the future) device drivers are compiled into the kernel once, in order to solve this problem, Linux proposed loadable kernel module (Loadable Kernel MODULE,LKM) concept, allows a device to drive through the mode of module loading, after the kernel is running "into" the kernel, the module loaded into the kernel and itself is compiled into the kernel module exactly the same.
The relative relationship of a program in the compiled address has been determined, the runtime is only a simple offset, in order to make the module loaded into the kernel can be placed in the correct address, and correctly call the system to run the export symbol table, compile the module must use the system's compiled address, and call the system to compile a static export symbol table. That is, the module must use the System configuration environment: Makefile+.config, once the two files any change, it is likely to cause the module's compiled address and the system's compiled address does not match, resulting in runtime errors or even downtime.

Export symbol table

From the point of view of providing system operation efficiency, a module is not and should not be completely independent, that is, a module will often invoke the functions provided by other modules to achieve their own functions, which will better realize the division of the system and improve efficiency. In order to realize the mutual invocation between the modules, Linux has designed the export symbol table , each module can export its own private label to the system level, so that the label is visible to other modules, When compiling a module, the system automatically exports the exported symbol table of this module to the modules.syms file (which can be empty if no symbol is exported), and automatically merges the exported symbol table of the module with the Export symbol table of the system itself when loading a module. A system of source code export symbol table is generally in the source top-level directory of the modules.syms file, view the running System export symbol table using cat/proc/kallsyms. Note that, as explained earlier, the reason why our modules are working properly is that the symbolic address used to compile our module is the symbolic address used to compile the kernel, so the address is offset, but the address of the associated symbol in the module will also be offset with the kernel address, and can be found. Based on this idea, we can also directly view the current operating address of the system, assign the address to a function pointer and use, it is not a problem, of course, this is only the principle of elaboration, not recommended to write the module.
The following example shows that the compiled address is not the same as the run-time address:

The export of symbol table can greatly improve the efficiency of the system, which is only open source system to provide a powerful feature, but the introduction of the export symbol table will lead to a small trouble-the module's dependence, when we use lsmod , we can view the system's current module, The last two columns are the number of times the module is referenced and the kernel module that refers to the module, when a module is referenced by other modules, we cannot unload, similarly, if module a depends on module B, then module A does not load if module B does not load. This is especially important when writing multiple modules, and you can write a script to manage multiple dependent modules. The Linux kernel uses two macros to export symbols for a module

EXPORT_SYMBOL(符号名)EXPORT_SYMBOL_GPL(符号名)

Module Compilation method

With the kernel makefile, the compiled Xxx.ko (Kernel Object) is an external module that can be loaded into the kernel, and in order to take advantage of the makefile of the kernel, we can write the makefile of the compiled external module in the following format:

ifneq ($(KERNELRELEASE),)    export-objs = demo.o    obj-m = extern.oelse    KERNELDIR :=  /lib/modules/$(shell uname -r)/build    PWD       := $(shell pwd)endifall:    $(MAKE) -C $(KERNELDIR) M=$(PWD) modulesclean:     .tmp_versions Module.symvers modules.order .tmp_versions .*.cmd *.o *.ko *.mod.c

This simple makfile is the use of Ubuntu host source code makefile to compile the module, learning the beginning of the module programming in the host to compile debugging more convenient, the following I explain this makefile, first of all, Our idea is to prepare our module through the kernel makefile, and once the kernel's makefile is executed, the KERNELRELEASE variable is assigned a value, so the first time we enter this makfile, this variable is still empty, so the part that executes- else - Assign a value to the relevant variable , make default compile the first target all , make -C $(KERNELRELEASE) is to go to the KERNELRELEASE specified directory and execute the inside of the makefile, obviously this is the top level of our kernel source makefile, the next option M=$(PWD) modules is passed in this top-level makefile parameter, indicating that I want to compile a module, the module is located in the M specified directory, so the kernel will be related to the configuration and finally into the "directory of this module", at this time, our makefile will be entered again, This time is from the kernel makefile to jump in here, KERNELRELEASE has been defined, the kernel makefile want is the obj-m later specified to compile the target file, so the kernel makfile will find our written module source files to compile. So we get the Xxx.ko file that can be executed under Ubuntu, if you need to run it on the board, just change the kernel path to the source path of the board running system, and remember to export the relevant environment variables (ARCH, Cross_compile )

Registration/Logoff Module

Linux has a corresponding address reserved for each module, and registering the module makes the module visible to the kernel, which is also a prerequisite for module work. Once registered, we can view the operation of the module by looking at the kernel output information dmesg command. Kernel functions are often used printk() to output system information for print debugging. Use insmod Xxx.ko to load a module, use rmmod Xxx.ko to unload a module, use lsmod to view the modules in the current system and their references
Insmod uses a init_module() system call, and the implementation of this system call issys_init_module()
rmmod uses delete_module() system calls, the implementation of this system call issys_delete_module()

Program Framework for Modules

#Include<linux/init.h>#Include<linux/module.h>#Include<linux/errno.h>/* Construction/destructor */Staticint __InitMydemo_init(void) {//construction device/driver object //Initialize device/Drive object // Register device/Drive object //Necessary hardware initialization} static  void __exit mydemo_exit (void) {//Recycle resources //logoff device/Drive Object} /* load/Unload module */module_init (mydemo_init); Module_exit (Mydemo_exit); /* authorization */module_license ( "GPL"); Module_author ( "XJ"); Module_descriptipon ( "Mymydemo");  /* Export symbol */export_symbol (data);              

Note that the authorization here is necessary, if a module is not authorized, then a lot of functions that require this authorization can not even use, in the same vein, inappropriate authorization will also cause the module to run or load errors, so beginners must not ignore this authorization, the relevant licensing options in the "linux/module.h " in, here I put the relevant instructions for everyone to refer to

/* * The following license idents is currently acceptedAs indicating free * software modules * *"GPL" [GNUpublic License v2 or later] *  "GPL v2 "[GNU public License v2] * " GPL and additional rights "[GNU public License v2 rights and More] *  "Dual BSD /GPL "[GNU public License v2 * or BSD License Choice] *  "Dual MIT/GPL" [GNU public License v2 * or MIT License Choice] *  "Dual MPL/GPL" [GNU public License v2 * or Mozilla License Choice] * * The following other idents is available * *  "Pr Oprietary "[Non free Products] */           

Another detail is the Linux kernel source code of the default header file path is the top-level directory of the Include directory, so include the header file can be omitted,

First Linux Module

#Include<linux/kernel.h>#Include<linux/init.h>#include <linux/module.h> static int __init demo_init (void) {PRINTK (Kern_info" demo_init:%s,%s,%d "__file__,__func__,__line__); return 0;} static void __exit demo_exit ( void) {PRINTK (Kern_info "GPL");           

Perform insmod Xjdemo.koto view execution results

Module Transfer Parameters

The modules we write can also pass in parameters at Insmod, and Linux provides several macros (functions) for receiving external parameters. These functions are used inside the module, simply perform insmod Xjdemo.ko num=2,insmod mydemo.koi=10,insmod mydemo.ko extstr= "Hello" parameters can be passed into the module by the command

module_param(num,type,perm);    //接收一个传入的int数据module_param(num,type,perm); //接收一个传入的charp数据module_param_array(num,type,nump,perm); //接收一个数组module_param_string(name,string,len,perm); //接收一个字符串MODULE_PARAM_DESC("parameter description");

Category: Lv3_linuxkernel_analysis Tags: Linux module programming framework

Linux Module Programming framework