Reuse of Linux code and forced uninstallation of Linux drivers

(i) Reuse of Linux code

reuse = static reuse (the code that will be reused is declared in the header file of other files) + dynamic reuse (using resources from another Linux driver, such as functions, variables, macros, etc.)

1. Compilation is a Linux driver composed of multiple files (static reuse)

For complex Linux drivers, it is necessary to use multiple source code files to store different function code, which facilitates code classification and management, then you have to compile multiple source code files, and eventually build the. ko file or compile into the Linux kernel

The following is a description of compiling 3. c files into 3. o files, and linking the 3. o files to a. ko file--static reuse

Suppose C language source code files have main.c, fun.c, product.c, Product.h, where Main.c is a Linux-driven main program, in FUN.C and product.c, The functions used in MAIN.C are defined and implemented in Product.h, using functions in fun.c with the extern keyword in main.c, using functions from Product.h files by including product.c files

The most critical step is to write a makefile file

#Makefile

Obj-m: = Multi_file_driver (the directory where the files are located). O

Multi_file_driver-y: = MAIN.O fun.o PRODUCT.O

In summary, when compiling multiple source code files in the C or C + + language, if A.C uses the functions in the B.C file, you need to use extern to pre-define the functions in B.C in the A.c file, and extern is to tell the compiler the function name, number of arguments, parameter type, return value type, When you link A.O and b.o to an executable file or library, the compiler then looks for a specific implementation of the function in B.O. In addition, you can use the B.h file to define functions in B.C, and then include B.h files in A.C.

2. reliance on Linux driver modules (dynamic reuse)

Use the exported symbols (constants, variables, functions, etc.) in another driver module in one drive module

Below, the example consists of two Linux drivers (Symbol_producer and Symbol_consumer), where Symbol_producer (Symbol_ The producer.c file) drives two functions (add and sub) and Symbo_const constants and result variables are exported, while in Symbol_consumer (Symbol_ CONCUMER.C file), the 4 exported symbols are used in the driver.

SYMBOL_PRODUCER.C file part of the code is as follows://Export the Add function

Export_symbol (add);

Export the result variable

Exprort_symbol (result);

Export a sub function, using EXPROT_SYMBOL_GPL exported symbols

EXPORT_SYMBOL_GPL (sub);

Export Symbol_const Constants

EXPORT_SYMBOL_GPL (Symbol_const);

Some of the code in the Symbol_consumer.c file is as follows: extern const char* symbol_const;//defines the exported constants

extern int result;//defines the exported variable

extern int Add (int x1,int x2);//define the exported Add function

extern int sub (int x1,int x2);//define the exported sub function

Since there are two Linux drivers, it is necessary to specify two Linux modules in the makefile file, the code is as follows:

#Makefile

Obj-m: = SYMBOL_CONSUMER.O

Obj-m +=SYMBOL_PRODUCER.O

Note: Before installing Symbol_consumer, you need to install Symbol_producer, which is the reverse order of uninstallation.

(ii) forcibly uninstalling Linux drivers

Scenario 1: Initialization function crashes

Because the initialization function of the Linux driver module crashes, which causes the initialization function to not return normally, the current Linux driver module is not used by any other Linux driver, but it shows that it has been applied once

The key is that the value of the reference counter is inconsistent with the reference. Only need to clear the current Linux Driver Module reference counter 0, modify the counter can use the following two functions

is the reference counter for the Linux driver module that the module points to, plus 1, successfully returning 1, and failing to return 0

static inline int try_module_get (struct module *module);

is a reference counter minus 1 for the Linux driver module that the module points to

extern void Module_put (struct module *module);

Scenario 2: The Unload function is blocked

When uninstalling the Linux driver using the Rmmod command, the system calls the Unload function, and only if the Unload function returns successfully, the Linux driver is unloaded, and if the Unload function is blocked, the Rmmod command is blocked, which means that the code to unload the Linux driver module will never be executed. The performance of this situation is that an execution Rmmod command will stop there and never return to the operating prompt of the system

The problem with this is that the Unload function simply replaces the original unload function with an empty unload function.

In short, both situations have to solve an unavoidable problem, which is to get the module struct pointer that represents the Linux driver module to unload.

Reuse of Linux code and forced uninstallation of Linux drivers