Linux kernel cross-version driving implementation method and device and medium

Abstract

The embodiment of the invention discloses a Linux kernel cross-version driving implementation method and device and a medium, and the method comprises the steps: carrying out the instantiation of a function pointer in a newly-added structural body through employing a newly-added instrumentation eBPF program in a device driving frame in a kernel during the initialization of a device driver, so as to point to a function in the structural body, and carrying out the instantiation of the function pointer in the structural body; the function in the structural body is a drive function of a new version realized in an eBPF program; a user program accesses the device through system calling, when a kernel calls the old-version driving function in the file opportunions structural body of the general character type device driving framework, the eBPF program is used for carrying out hook association on the old-version driving function and the corresponding new-version driving function, the old-version driving function is intercepted, and the new-version driving function is intercepted; and turning to execute the driving function of the new version. And the problem of compatibility of the kernel with the driving module in kernel version evolution is avoided.

Description

Technical Field

[0001] The present invention relates to the field of drive technology, and in particular, to a method, device, and medium for implementing cross-version drivers in the Linux kernel. Background Art

[0002] With the rapid development of Linux, it is necessary to adapt the peripherals of different computer devices to the Linux kernel, including but not limited to graphics cards, network cards, sensors, and FPGA devices. These devices come from different manufacturers, and the drivers of the devices are usually developed and maintained by the manufacturers. When integrating with the Linux kernel, the driver is compiled into a ko file, and the insmod command is used to install the ko file into the system to make it run and drive the corresponding device.

[0003] During the evolution of the Linux kernel version, structures, unions, functions, etc. defined in the kernel code will inevitably change. Similarly, the definitions of functions will also have changes in parameters, renaming, or disappearance. Therefore, changes in the kernel version will cause the kernel to report errors when the system runs insmod to install the ko file from the manufacturer. At the same time, there will also be a situation where the installed driver is not compatible with the kernel, affecting the normal operation of the device. Summary of the Invention

[0004] Embodiments of the present invention provide a method, device, and medium for implementing cross-version drivers in the Linux kernel to solve the technical problem that device drivers cannot be installed and compatible normally due to the evolution of the Linux kernel version in the prior art.

[0005] In a first aspect, embodiments of the present invention provide a method for implementing cross-version drivers in the Linux kernel, including: During the initialization of the device driver, the function pointers in the newly added file_operations_ext structure are instantiated by using the newly added staking eBPF program in the device driver framework in the kernel to point to the functions in the file_operations_ext structure, and the functions in the file_operations_ext structure are the new version of the driver functions implemented in the eBPF program; When the user program accesses the device through a system call and the kernel calls the old version of the driver function in the file_operations structure of the general character device driver framework, the eBPF program is used to hook and associate the old version of the driver function with the corresponding new version of the driver function to intercept the old version of the driver function and turn to execute the new version of the driver function.

[0006] In a second aspect, embodiments of the present invention further provide a device for implementing cross-version drivers in the Linux kernel, including: An instantiation module, which is used to instantiate function pointers in a newly added file_operations_ext structure by using an inserted eBPF program newly added to the device driver framework in the kernel during device driver initialization, so as to point to functions in the file_operations_ext structure. The functions in the file_operations_ext structure are new versions of driver functions implemented in the eBPF program; An association module, which is used to hook and associate an old version of a driver function with a corresponding new version of the driver function by using the eBPF program when a user program accesses the device through a system call and the kernel calls the old version of the driver function in the file_operations structure of the general character device driver framework, so as to intercept the old version of the driver function and turn to execute the new version of the driver function.

[0007] In a third aspect, an embodiment of the present invention further provides a storage medium containing computer-executable instructions, and the computer-executable instructions are used to execute the Linux kernel cross-version driver implementation method provided in the above embodiment when executed by a computer processor.

[0008] The method, device and medium for implementing cross-version drivers of the Linux kernel provided by the embodiments of the present invention instantiate function pointers in a newly added file_operations_ext structure by using an inserted eBPF program newly added to the device driver framework in the kernel during device driver initialization, so as to point to functions in the file_operations_ext structure. The functions in the file_operations_ext structure are new-version driver functions implemented in the eBPF program. When a user program accesses the device through a system call and the kernel calls an old-version driver function in the file_operations structure of the general character device driver framework, the eBPF program is used to perform hook association between the old-version driver function and the corresponding new-version driver function, so as to intercept the old-version driver function and turn to execute the new-version driver function. It is possible to instantiate function pointers in a newly added structure by using an inserted eBPF program newly added to the kernel, and correspondingly point to new-version driver functions. When calling the device, when an old-version function in the original file_operations structure in the running kernel is called, the eBPF program is used to hook and associate it to the new-version driver function pointed to by the function pointer in the file_operations_ext structure, which can intercept the old-version driver function and turn to execute the new-version driver function. This avoids compatibility problems of the kernel with driver modules during kernel version evolution. And it is possible to avoid modifying the kernel, reducing factors affecting security and stability. At the same time, the maintenance cost of the driver program is reduced, and there is no need to modify and test the driver code at any time following the kernel. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Other features, objects and advantages of the present invention will become more apparent by reading the detailed description of the non-limiting embodiments with reference to the following drawings: Figure 1 is a flowchart of the method for implementing cross-version drivers of the Linux kernel provided by Embodiment 1 of the present invention; Figure 2 is a flowchart of the method for implementing cross-version drivers of the Linux kernel provided by Embodiment 2 of the present invention; Figure 3 is a structural diagram of the device for implementing cross-version drivers of the Linux kernel provided by Embodiment 3 of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0010] The present invention will be further described in detail below with reference to the drawings and embodiments. It can be understood that the specific embodiments described herein are only used to explain the present invention, rather than limiting the present invention. In addition, it should be noted that, for the sake of description, only parts related to the present invention are shown in the drawings rather than all structures.

[0011] Example 1 Figure 1 FIG. 5 is a flowchart of a method for implementing a Linux kernel cross-version driver provided in Example 1 of the present invention. This example can be directed to the evolution of the kernel version. This method can be executed by a Linux kernel cross-version driver implementation device, and specifically includes the following steps: Step 110, when initializing a device driver, instantiate function pointers in a newly added file_operations_ext structure using a newly added staking eBPF program in the device driver framework in the kernel to point to functions in the file_operations_ext structure, where the functions in the file_operations_ext structure are new version driver functions implemented in the eBPF program.

[0012] Due to the evolution of the Linux kernel, changes occur in the kernel. Specifically, the following changes may occur: structures, unions, functions, etc. defined in the code may change. For example, the following structure is defined in an old version: struct foo { uint32_t a; uint32_t b; uint16_t c; }; In the evolved new version, it is defined as: struct foo { uint32_t a; uint32_t b; uint16_t c; Int

[16] d; }; It can be seen from the above that when the Linux kernel evolves from an old version to a new version, the defined structure changes.

[0013] In addition, when the Linux kernel evolves from an old version to a new version, the definition of a function may also have changes in parameters, renaming, or disappearance. For example, the function defined in the old version of the Linux kernel is int foo(void *ctx); The corresponding function in the new version is defined as: int foo(void *ctx, int flags). Since there is no backward compatibility mechanism for kernel changes, this will cause the same version of the driver to be incompatible with different versions of the kernel. Therefore, peripheral device manufacturers need to modify the driver code at any time following the kernel and add it to the kernel module, greatly increasing the maintenance cost of the driver program.

[0014] In this embodiment, a new structure can be established in advance. The new structure can be named file_operations_ext. The newly added file_operations_ext structure includes: A group of function pointers and a corresponding group of new version driver functions. The new version driver functions adaptively modify parameters according to the modified content of the new version kernel. The new version driver functions can be adaptively modified for structure, function, and union changes, and also modified for changes in function names, etc., so as to adapt to the evolved new kernel and realize the driver function in the new version kernel.

[0015] Correspondingly, an inlined eBPF program can be added to the device driver framework in the new version kernel. The device driver framework in Linux realizes the unified management of hardware resources through a hierarchical design, dynamic loading, and event-driven model. The eBPF program provides highly flexible programmable capabilities for the Linux kernel while ensuring security.

[0016] When the kernel initializes the device driver and executes to the inlined eBPF program, the eBPF program can instantiate the function pointers in the newly added structure, that is, modify the function pointers from the original null values to the addresses corresponding to the functions adapted to the new kernel version, facilitating the call of the corresponding new version driver functions.

[0017] Step 120, when the user program accesses the device through a system call and the old version driver function is called in the file_operations structure of the general character device driver framework in the kernel, the eBPF program is used to hook-associate the old version driver function with the corresponding new version driver function, intercept the old version driver function, and redirect to execute the new version driver function.

[0018] Since the corresponding device has been registered in the new version kernel during initialization and a character device node is obtained, when the system kernel remains unchanged, the application program can call the device through the original file_operations structure open / read / write / close and other driver functions of the general character device driver framework. In this embodiment, this logic continues to be executed, and the eBPF program is used to hook-associate the old version driver function with the corresponding new version driver function, intercept the old version driver function, and redirect to execute the new version driver function.

[0019] Exemplarily, the process of using the eBPF program to hook and associate an old version of a driver function with its corresponding new version of the driver function may include: obtaining a pointer to the old version of the driver function; filling the hook structure according to the pointer to the instantiated new version of the driver function to achieve the hook association between the old version of the driver function and its corresponding new version of the driver function.

[0020] In the file_operations structure, there are also function pointers that point to the original driver functions. After a new version is formed during the evolution of the kernel version, to avoid crashes caused by redirecting to the original driver functions, in this embodiment, the eBPF program can be used to point these function pointers to the driver functions in the file_operations_ext structure. The pointer to the read call function in the file_operations structure can be used as a hook point to redirect to the function pointer in the instantiated file_operations_ext, and then redirect to execute the new version of the driver function.

[0021] Exemplarily, when system calls such as open / read / write and other device functions are made, the above method can be used to intercept the driver functions that implement devices such as open / read / write pointed to by the pointer functions in the file_operations structure and switch to execute the new version of the driver functions in the file_operations_ext structure. This realizes intercepting the original processing logic and redirecting to the new driver processing logic.

[0022] In this embodiment, the kernel manager can detect the memory and loop logic of the eBPF program when loading and compiling the eBPF program, which provides technical guarantees for the security and stability of both the eBPF program and the kernel. When the above driver implementation is adopted, the security of the kernel is ensured.

[0023] In this embodiment, during the initialization of the device driver, the function pointers in the newly added file_operations_ext structure are instantiated by using the inserted eBPF program newly added to the device driver framework in the kernel, so as to point to the functions in the file_operations_ext structure implemented in the eBPF program. The functions in the file_operations_ext structure are the new version of the driver functions implemented in the eBPF program. When the user program accesses the device through a system call, when the kernel calls the old version of the driver function in the file_operations structure of the general character device driver framework, the eBPF program is used to hook and associate the old version of the driver function with the corresponding new version of the driver function, so as to intercept the old version of the driver function and turn to execute the new version of the driver function. It is possible to instantiate the function pointers in the newly added structure by using the inserted eBPF program newly added to the kernel, corresponding to point to the new version of the driver function. When calling the device, when the old version function in the original file_operations structure in the kernel is running, the eBPF program is used to hook and associate it with the new version of the driver function pointed to by the function pointer in the file_operations_ext structure, which can intercept the old version of the driver function and turn to execute the new version of the driver function. This avoids the compatibility problem of the kernel with the driver module during the evolution of the kernel version. And it is possible to avoid modifying the kernel, reducing the factors affecting security and stability. At the same time, it reduces the maintenance cost of the driver program and does not need to modify and test the driver code at any time following the kernel.

[0024] In a preferred implementation manner of this embodiment, the method may further include the following steps: query the kernel functions related to the device; add the definition of the kernel functions as auxiliary functions for accessing kernel functions, so that the new version of the driver function uses the eBPF program to apply for and release the buffers required by the device and process the commands and information for device operations according to the user program's call of the kernel functions. Since the eBPF program cannot directly call the kernel functions, the eBPF program cannot directly use some kernel functions and variables of the device. For example: calling the kernel functions to apply for and release the buffers required by the device and process the commands and information for device operations. Such as: interrupt and other information. Exemplarily, the functions can be defined as the __bpf_kfunc type, and in this embodiment, the following several types can be included: ebpf_request_irq; ebpf_dma_alloc_coherent, which can implement calling the kernel interrupt function and applying for the buffers required by the device.

[0025] Embodiment 2 Figure 2It is a flowchart showing the implementation method of cross-version drivers in the Linux kernel provided in the second embodiment of the present invention. This embodiment is optimized based on the above embodiment. The newly added file_operations_ext structure is specifically optimized as: a set of function pointers and a corresponding set of new-version driver functions pointed to. The new-version driver functions are implemented in the eBPF program and are the upgraded driver functions when the kernel remains unchanged. Correspondingly, the method can also add the following steps: when the user program fails to access the device through a system call, unload the loaded eBPF program in the kernel so that the function pointers in the file_operations_ext structure are 0; re-initialize the device driver again. When the user program accesses the device through a system call, use the file_operations structure to call the old-version driver functions.

[0026] See Figure 2 , the implementation method of the cross-version driver in the Linux kernel includes: Step 210, during device driver initialization, use the newly added staking eBPF program in the device driver framework in the kernel to instantiate the function pointers in the newly added file_operations_ext structure to point to the functions in the file_operations_ext structure. The functions are implemented in the eBPF program and are the upgraded driver functions when the kernel remains unchanged.

[0027] Step 220, when the user program accesses the device through a system call and the old-version driver functions are called in the file_operations structure of the general character device driver framework in the kernel, use the eBPF program to hook and associate the old-version driver functions with the corresponding new-version driver functions to intercept the old-version driver functions and turn to execute the new-version driver functions.

[0028] Step 230, when the user program fails to access the device through a system call, unload the loaded eBPF program in the kernel so that the function pointers in the file_operations_ext structure are 0.

[0029] In this embodiment, the above method can be used to upgrade the device driver when the kernel has not evolved. However, the upgraded driver may have problems. Therefore, it is necessary to perform a rollback operation to return the driver to the version before the upgrade to ensure that the device can be used normally.

[0030] When the user program fails to access the device through a system call, it can be determined that there is an exception in the new version of the driver function. Therefore, in this embodiment, the eBPF program in the kernel can be uninstalled. Exemplarily, the ID of the eBPF program in the kernel can be queried, and then the eBPF program can be removed according to the ID. To execute the original device driver logic.

[0031] Step 240, perform device driver initialization again. When the user program accesses the device through a system call, the old version of the driver function is called using the file_operations structure.

[0032] Perform device driver initialization again. Since the eBPF program has been removed, the function pointers in the newly added file_operations_ext structure are not initialized, so they are all initial values of 0.

[0033] When the user program accesses the device through a system call, since the eBPF program has been removed, the function pointers in the file_operations_ext structure are initial values, making the original hook functions ineffective. The original driver function pointed to by the function pointer in the file_operations structure is still executed. That is, it is executed according to the original device driver logic. Using this method, the newly added driver function can be skipped, errors can be avoided, and the rollback of the original driver can be achieved. Ensure the normal operation of the device in the system.

[0034] In this embodiment, the newly added file_operations_ext structure is specifically optimized as: a set of function pointers and a corresponding set of new version of driver functions implemented in the eBPF program, which are upgraded driver functions when the kernel remains unchanged. Correspondingly, the method can also add the following steps: when the user program fails to access the device through a system call, unload the loaded eBPF program in the kernel to make the function pointers in the file_operations_ext structure 0; perform device driver initialization again. When the user program accesses the device through a system call, the old version of the driver function is called using the file_operations structure. Using the above method, when there is a problem with the new version of the driver, it can be rolled back to the old version of the driver that could be used normally before without having to perform a large number of operations on the device driver again, reducing the difficulty and workload of driver rollback.

[0035] In a preferred implementation manner of this embodiment, the method may further include the following steps: when the eBPF program is loaded into the kernel, use the JIT compiler to convert it into instructions matching the hardware architecture; use the verification tool to perform static analysis on the eBPF program, and the abstract interpretation technology simulates the program execution path to ensure the security and correctness of the eBPF program; use the compiler to compile the statically analyzed eBPF program to form the eBPF program bytecode. The compatibility problem caused by the differences in data structures and symbols between different kernel versions can be solved through the CO-RE technology of eBPF. Embedding metadata describing the kernel data structure in the compilation stage enables the same eBPF code to run adaptively on multiple kernel versions. Further, the eBPF program bytecode can be copied and transplanted into the Linux kernel of other terminals. Further reduces the usage difficulty of the Linux kernel cross-version driver implementation method.

[0036] Embodiment III Figure 3 is a schematic structural diagram of the Linux kernel cross-version driver implementation device provided in Embodiment III of the present invention. Refer to Figure 3 , the Linux kernel cross-version driver implementation device includes: The instantiation module 310 is used to instantiate the function pointers in the newly added file_operations_ext structure using the newly added stubs eBPF program in the device driver framework in the kernel during device driver initialization, so as to point to the functions in the file_operations_ext structure. The functions in the file_operations_ext structure are the new version of the driver functions implemented in the eBPF program; The association module 320 is used to, when the user program accesses the device through a system call and the kernel calls the old version of the driver function in the file_operations structure of the general character device driver framework, use the eBPF program to perform hook association between the old version of the driver function and the corresponding new version of the driver function, so as to intercept the old version of the driver function and turn to execute the new version of the driver function.

[0037] The Linux kernel cross-version driver implementation device provided in this embodiment instantiates function pointers in the newly added file_operations_ext structure by using the newly added staking eBPF program in the device driver framework of the kernel during device driver initialization, so as to point to the functions in the file_operations_ext structure. The functions in the file_operations_ext structure are the new version of the driver functions implemented in the eBPF program. When the user program accesses the device through a system call and the kernel calls the old version of the driver function in the file_operations structure of the general character device driver framework, the eBPF program is used to perform hook association between the old version of the driver function and the corresponding new version of the driver function, so as to intercept the old version of the driver function and turn to execute the new version of the driver function. It is possible to instantiate the function pointers in the newly added structure by using the newly added staking eBPF program in the kernel, and correspondingly point to the new version of the driver function. When calling the device, when the old version function in the original file_operations structure in the running kernel is called, the eBPF program is used to hook and associate it to the new version of the driver function pointed to by the function pointer in the file_operations_ext structure, which can intercept the old version of the driver function and turn to execute the new version of the driver function. This avoids the compatibility problem of the kernel with the driver module during the evolution of the kernel version. And it is possible to avoid modifying the kernel, reducing the factors affecting security and stability. At the same time, it reduces the maintenance cost of the driver program and does not need to modify the test driver code at any time following the kernel.

[0038] Based on the above embodiments, the association module includes: An acquisition unit, configured to acquire a pointer to the old version of the driver function; A filling unit, configured to fill the hook structure according to the pointer to the instantiated new version of the driver function, so as to implement hook association between the old version of the driver function and the corresponding new version of the driver function.

[0039] Based on the above embodiments, the device further includes: A query module, configured to query kernel functions related to the device; An addition module, configured to add the kernel function as an auxiliary function for accessing kernel functions, so that the new version of the driver function uses the eBPF program to apply for and release buffers required by the device and process commands and information for device operations according to the user program's call of the kernel function.

[0040] Based on the above embodiments, the newly added file_operations_ext structure includes: A set of function pointers and a corresponding set of new versions of driver functions, where the new versions of driver functions are adaptively modified for the modifications in the new version of the kernel.

[0041] Based on the above embodiments, the newly added file_operations_ext structure includes: A set of function pointers and a corresponding set of new versions of driver functions pointed to, where the new versions of driver functions are implemented in the eBPF program and are driver functions for upgrading when the kernel remains unchanged.

[0042] Based on the above embodiments, the device further includes: An unloading module, configured to unload the loaded eBPF program in the kernel when the user program fails to access the device through a system call, so that the function pointers in the file_operations_ext structure are 0; A calling module, configured to re-initialize the device driver again, and when the user program accesses the device through a system call, call the old version of the driver function using the file_operations structure.

[0043] Based on the above embodiments, the device further includes: When the eBPF program is loaded into the kernel, use the JIT compiler to convert it into instructions matching the hardware architecture; Use a verification tool to perform static analysis on the eBPF program, and use abstract interpretation technology to simulate the program execution path to ensure the security and correctness of the eBPF program; Use a compiler to compile the statically analyzed eBPF program into eBPF program bytecode.

[0044] Based on the above embodiments, the device further includes: A copying module, configured to copy and transplant the eBPF program bytecode into the Linux kernel of other terminals.

[0045] The Linux kernel cross-version driver implementation device provided by the embodiments of the present invention can execute the Linux kernel cross-version driver implementation method provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0046] Embodiment 4 Embodiment 4 of the present invention further provides a storage medium containing computer-executable instructions, and the computer-executable instructions are used to execute any one of the Linux kernel cross-version driver implementation methods provided by the above embodiments when executed by a computer processor.

[0047] The computer storage medium of an embodiment of the present invention may adopt any combination of one or more computer-readable media. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples (non-exhaustive list) of the computer-readable storage medium include: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0048] The computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries the computer-readable program code. Such a propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer-readable signal medium may also be any computer-readable medium other than the computer-readable storage medium, which can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0049] The program code contained on the computer-readable medium may be transmitted by any appropriate medium, including but not limited to wireless, wire, optical fiber cable, RF, etc., or any suitable combination of the above.

[0050] The computer program code for performing the operations of the present invention may be written in one or more programming languages or combinations thereof. The programming languages include object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or device. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0051] Note that the above is only a preferred embodiment of the present invention and the technical principles applied. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein. Various obvious changes, re-adjustments, and substitutions can be made by those skilled in the art without departing from the protection scope of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments. Without departing from the concept of the present invention, it may also include more other equivalent embodiments, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A Linux kernel cross-version driver implementation method, characterized in that: include: When the device driver is initialized, the function pointer in the newly added file_operations_ext structure is instantiated using the newly added stub eBPF program in the device driver framework in the kernel to point to the function in the file_operations_ext structure. The function in the file_operations_ext structure is the new version of the driver function implemented in the eBPF program. The user program accesses the device through a system call. When the kernel calls the old version of the driver function in the file_operations structure of the general character device driver framework, the eBPF program is used to hook the old version of the driver function with the corresponding new version of the driver function, so as to intercept the old version of the driver function and switch to executing the new version of the driver function.

2. The method according to claim 1, characterized in that The method of using the eBPF program to hook the old version of the driver function with the corresponding new version of the driver function includes: Get the pointer of the old version of the driver function; The hook structure is filled according to the pointer of the instantiated new version driver function to realize the hook association between the old version driver function and the corresponding new version driver function.

3. The method according to claim 1, characterized in that The method further comprises: Query device-related kernel functions; The kernel function definition is added as an auxiliary function for accessing kernel functions, so that the new version of the driver function uses the eBPF program to call the kernel function according to the user program, apply for and release the buffer required by the device, and process the commands and information for device operations.

4. The method according to claim 1, characterized in that: The newly added file_operations_ext structure includes: A set of function pointers and a corresponding set of new version driver functions, wherein the new version driver functions modify parameters adaptively according to the modified content of the new version kernel.

5. The method according to claim 1, characterized in that The newly added file_operations_ext structure includes: A set of function pointers and a corresponding set of new versions of driver functions, wherein the new versions of the driver functions are implemented in the eBPF program and are upgraded driver functions without changing the kernel.

6. The method according to claim 5, characterized in that The method further comprises: When the user program fails to access the device through a system call, the loaded eBPF program is unloaded in the kernel so that the function pointer in the file_operations_ext structure is 0; The device driver is initialized again, and when the user program accesses the device through a system call, the old version of the driver function is called using the file_operations structure.

7. The method according to claim 1, characterized in that The method further comprises: When the eBPF program is loaded into the kernel, it is converted into instructions that match the hardware architecture using the JIT compiler; Use verification tools to perform static analysis on eBPF programs, and use abstract interpretation technology to simulate program execution paths to ensure the security and correctness of eBPF programs. The compiler is used to compile the statically analyzed eBPF program into eBPF program bytecode.

8. The method according to claim 7, characterized in that The method further comprises: Copy and port the eBPF program bytecode to the Linux kernel of other terminals.

9. A Linux kernel cross-version driver implementation device, characterized in that: include: An instantiation module is used to instantiate the function pointer in the newly added file_operations_ext structure using the newly added stub eBPF program in the device driver framework in the kernel when the device driver is initialized, so as to point to the function in the file_operations_ext structure, where the function in the file_operations_ext structure is the new version of the driver function implemented in the eBPF program; The association module is used to use the eBPF program to hook the old version of the driver function with the corresponding new version of the driver function when the user program accesses the device through a system call and calls the old version of the driver function in the file_operations structure of the kernel calling the universal character device driver framework, so as to intercept the old version of the driver function and switch to executing the new version of the driver function.

10. A storage medium containing computer executable instructions, characterized in that: The computer executable instructions, when executed by a computer processor, are used to execute the Linux kernel cross-version driver implementation method as described in any one of claims 1-8.

Images