Driving frame and driving processing method and device

Abstract

The invention relates to a driving framework, which can be mounted in different types of OS (Operating System), and comprises a driving API (Application Program Interface) coupled with a driving module; the user mode implementation module of the driving API interface provides a first implementation logic for responding to an instruction of a driving module received by the driving API interface when the OS is in a user mode; and the kernel mode implementation module of the driving API interface provides second implementation logic for responding to the instruction of the driving module received by the driving API interface when the OS is in the kernel mode. Development of the driving program can be simplified, and the purpose that one set of driving program can be applied to a kernel mode and a user mode is achieved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a driver framework, a driver processing method and apparatus, a computing device, and a storage medium. Background Art

[0002] Computing devices (such as computers, industrial personal computers, and embedded devices) consist of multiple hardware devices (such as serial port chips, storage media, cameras, graphics cards, and sound cards) and operating systems (such as Intel, Linux, real-time operating systems, and embedded operating systems). Applications can be installed within the operating system. To enable the operating system to access the hardware devices, and to enable applications to access the hardware devices through the operating system, the operating system also installs drivers for the corresponding hardware devices.

[0003] A driver is a special software program that acts as a bridge between the hardware and the operating system, enabling data transfer between the operating system and the hardware device. The driver's primary function is to enable the operating system to identify, configure, manage, and control hardware devices, ensuring they function properly and collaborate with the corresponding applications in the operating system. For example, the driver provides the operating system with a set of application programming interfaces (APIs), through which the operating system or applications can read, write, and control hardware devices. In another example, hardware devices typically use interrupts to notify the operating system of specific events (such as data readiness or errors). The driver needs to register and handle these interrupts to respond promptly to changes in device status.

[0004] Currently, based on security requirements, operating systems provide two working modes: kernel mode and user mode. A brief introduction is as follows:

[0005] Kernel mode: Also known as privileged mode or supervisor mode, when the operating system runs in kernel mode, it has unrestricted access to all computer resources, including hardware resources (such as memory, CPU registers, I / O devices, etc.) and all system call services. Kernel mode can execute all types of instructions, including privileged instructions.

[0006] User mode: This refers to the mode in which ordinary applications run, also known as non-privileged mode. Programs running in user mode are subject to strict permission restrictions and cannot directly access any memory area or operate hardware devices. When an application needs to perform operations involving system resources, such as reading and writing disks, creating processes, or network communications, it can switch to kernel mode (if allowed) to execute, or receive instructions through an agent in the operating system kernel (the operating system kernel is always in kernel mode) and verify the execution of the relevant operations.

[0007] Currently, when developing drivers for kernel-mode, they are developed directly using kernel interfaces (referring to the operating system kernel's API), which are referred to as kernel-mode drivers. Kernel-mode drivers generally cannot be run directly in user-mode. This is because kernel-mode drivers need to access and control underlying hardware resources. These operations involve direct manipulation of core system resources and sensitive operations, requiring high privileges. User-mode programs, on the other hand, run at a relatively low privilege level, and their direct access to hardware resources must be restricted for system security and isolation. Therefore, kernel-mode drivers cannot be directly used in user-mode. Therefore, drivers must be redeveloped for user-mode, which can be referred to as user-mode drivers. For example, these can be developed based on the UIO (Userspace I / O) interface framework or the VFIO (Virtual Function I / O) interface framework used in user-mode.

[0008] Among them, users may have different needs for different scenarios. For example, users may have the need to put the operating system in kernel state. This is because when the driver runs in kernel state, although the security is relatively low (here, kernel state permissions are provided to users for use, resulting in low security), the operating efficiency will be higher. For another example, users may also have the need to put the operating system in user state. This is because when the driver runs in user state, the security will be higher (here, only user state permissions are provided to users for use, so the security is high). Therefore, users will switch the operating system between kernel state and user state based on different needs.

[0009] Therefore, when writing drivers for hardware, you need to write one set of drivers for kernel mode and another set for user mode to meet the needs of users in different scenarios. This makes the driver development cycle long and costly.

[0010] Therefore, in this context, how to provide a solution to simplify the development of drivers and implement the use of a set of drivers that can be applied to kernel mode and user mode to meet the needs of users in different scenarios is a technical problem that needs to be solved. Summary of the Invention

[0011] In view of the above problems in the prior art, the present application provides a driver framework, a driver processing method and device, a computing device and a storage medium to simplify the development of the driver program and realize the use of a set of drivers that can be applied to kernel mode and user mode.

[0012] To achieve the above objectives, the first aspect of the present application provides a driver framework that can be mounted on different types of OS, and the driver framework includes:

[0013] Driver API interface coupled with the driver module;

[0014] The user-mode implementation module of the driver API interface provides a first implementation logic for responding to instructions of the driver module received by the driver API interface when the OS is in user mode;

[0015] The kernel state implementation module of the driver API interface provides a second implementation logic for responding to the instructions of the driver module received by the driver API interface when the OS is in kernel state.

[0016] As described above, this application can unify the driver-oriented API interface in user mode and kernel mode. This allows a set of drivers to be reused in kernel and user mode, thereby simplifying the driver development process and eliminating the need for repeated driver development work, shortening the development cycle and reducing development costs. On the other hand, the driver framework of this application decouples the driver and API parts, which facilitates the flexibility of driver development.

[0017] As a possible implementation of the first aspect, the driver API interface includes a first type API interface and a second type API interface, the first type API interface is set for accessing non-kernel resources, and the second type API interface is set for accessing kernel resources.

[0018] From the above, by classifying the driver API interfaces, it is convenient to set different implementation logic for different types of API interfaces.

[0019] As a possible implementation of the first aspect, the user-mode implementation module driving the API interface provides the first implementation logic including one of the following:

[0020] For instructions received through the first type of API interface, the operating system or application directly responds to the instructions received through the first type of API interface and performs corresponding operations on non-core resources;

[0021] For instructions received through the second type of API interface, the kernel of the operating system responds to the instructions received through the second type of API interface in a proxy manner and performs corresponding operations on kernel resources;

[0022] For instructions received through the second type of API interface, the kernel of the operating system responds to the instructions received through the second type of API interface in a spatial mapping manner and performs corresponding operations on kernel resources;

[0023] For the instructions received through the second type of API interface, the kernel of the operating system responds to the instructions received through the second type of API interface through a system call and executes corresponding operations on kernel resources.

[0024] From the above, for the first implementation logic in the user state, a specific logic can be flexibly selected to implement access to kernel resources in the user state.

[0025] As a possible implementation of the first aspect, the kernel-mode implementation module of the driver API interface provides the second implementation logic including one of the following:

[0026] For instructions received through the first type of API interface, the operating system or application directly responds to the instructions received through the first type of API interface and performs corresponding operations on non-core resources;

[0027] For instructions received through the second type of API interface, the kernel of the operating system directly responds to the instructions received through the driver API interface and performs corresponding operations on kernel resources.

[0028] As a possible implementation method of the first aspect, when the driver provided by the driver module is loaded by the user-state implementation module of the driver API interface or the kernel-state implementation module of the driver API interface, the driver in binary state is loaded on demand at runtime through dynamic linking technology.

[0029] As described above, dynamic linking technology can be used to load the required driver binary file when needed (such as when accessing the hardware device corresponding to the driver is required during program execution) in user mode or kernel mode.

[0030] A second aspect of the present application provides a method for processing a driver, based on any driver framework described in the first aspect, the method comprising:

[0031] Receive instructions from the driver module through the driver API interface;

[0032] When it is determined that the current OS is in user mode, responding to the instruction through the first implementation logic provided by the user mode implementation module of the driver API interface;

[0033] When it is determined that the current OS is in kernel mode, the instruction is responded to through the second implementation logic provided by the kernel mode implementation module of the driver API interface.

[0034] As a possible implementation of the second aspect, the driver API interface includes a first type of API interface and a second type of API interface, the first type of API interface is set to access non-kernel resources, and the second type of API interface is set to access kernel resources;

[0035] The user-mode implementation module driving the API interface provides the first implementation logic including one of the following:

[0036] For instructions received through the first type of API interface, the operating system or application directly responds to the instructions received through the first type of API interface and performs corresponding operations on non-core resources;

[0037] For instructions received through the second type of API interface, the kernel of the operating system responds to the instructions received through the second type of API interface in a proxy manner and performs corresponding operations on kernel resources;

[0038] For instructions received through the second type of API interface, the kernel of the operating system responds to the instructions received through the second type of API interface in a spatial mapping manner and performs corresponding operations on kernel resources;

[0039] For instructions received through the second type of API interface, the kernel of the operating system responds to the instructions received through the second type of API interface through a system call and performs corresponding operations on kernel resources;

[0040] The kernel-mode implementation module of the driver API interface provides the second implementation logic including one of the following:

[0041] For instructions received through the first type of API interface, the operating system or application directly responds to the instructions received through the first type of API interface and performs corresponding operations on non-core resources;

[0042] For instructions received through the second type of API interface, the kernel of the operating system directly responds to the instructions received through the driver API interface and performs corresponding operations on kernel resources.

[0043] A third aspect of the present application provides a drive processing device, comprising:

[0044] The receiving module is used to receive instructions from the driver module through the driver API interface;

[0045] A first processing module is configured to respond to the instruction through a first implementation logic provided by the user-state implementation module of the driver API interface when determining that the current OS is in user state;

[0046] The second processing module is used to respond to the instruction through the second implementation logic provided by the kernel state implementation module of the driver API interface when it is determined that the current OS is in kernel state.

[0047] A fourth aspect of the present application provides a computing device, comprising: a communication interface, and at least one processor; wherein the at least one processor is used to execute program instructions, and the program instructions, when executed by the at least one processor, enable the computing device to implement the above-mentioned method.

[0048] In a fifth aspect, the present application provides a computer-readable storage medium having program instructions stored thereon, which, when executed by a computer, enables the computer to implement the above-mentioned method. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 is a schematic diagram of a driving framework provided in an embodiment of the present application;

[0050] Figure 2 This is a schematic diagram of the driver API interface provided by an embodiment of the present application;

[0051] Figure 3 This is a schematic diagram of a user-mode implementation module for a driver API interface provided in an embodiment of the present application;

[0052] Figure 4 This is a schematic diagram of a kernel-mode implementation module for a driver API interface provided in an embodiment of the present application;

[0053] Figure 5 Schematic diagram of dynamic driver loading in user mode and kernel mode provided by an embodiment of the present application;

[0054] Figure 6 This is a schematic diagram of the UART driver API interface provided by an embodiment of the present application;

[0055] Figure 7 This is a schematic diagram of a user-mode implementation module of a UART driver API interface provided in an embodiment of the present application;

[0056] Figure 8 This is a schematic diagram of a kernel-mode implementation module of a UART driver API interface provided in an embodiment of the present application;

[0057] Figure 9 This is a flowchart of a method for processing a driver provided in an embodiment of the present application;

[0058] Figure 10 This is a flow chart of a device for processing a driver provided in an embodiment of the present application;

[0059] Figure 11 It is a structural schematic diagram of a computing device provided in an embodiment of the present application.

[0060] It should be understood that the sizes and shapes of the blocks in the above structural diagrams are for reference only and should not constitute an exclusive interpretation of the embodiments of the present invention. The relative positions and inclusion relationships between the blocks presented in the structural diagrams are merely schematic representations of the structural relationships between the blocks and do not limit the physical connection methods of the embodiments of the present invention. DETAILED DESCRIPTION

[0061] The technical solution provided by this application is further described below with reference to the accompanying drawings and examples. It should be understood that the system structure and business scenarios provided in the examples of this application are mainly for illustrating possible implementation methods of the technical solution of this application and should not be interpreted as the sole limitation of the technical solution of this application. It is known to those skilled in the art that with the evolution of the system structure and the emergence of new business scenarios, the technical solution provided by this application is also applicable to similar technical problems.

[0062] It should be understood that the driver framework solutions provided in the embodiments of this application include a driver framework, driver processing methods and devices, computing devices, and storage media. Because these technical solutions solve the same or similar problems, some repetitions may not be repeated in the following descriptions of the specific embodiments. However, these specific embodiments should be considered as having been referenced and can be combined with each other.

[0063] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. In the event of any inconsistency, the meanings described in this specification or the meanings derived from the contents recorded in this specification shall prevail. In addition, the terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application. In order to accurately describe the technical content in this application and to accurately understand the present invention, the following explanations or definitions are given for the terms used in this specification before describing the specific embodiments:

[0064] 1) Operating System Kernel: This refers to the core part of the operating system. It is the basic software layer in the computer system. The operating system kernel sits above the hardware and below all other application programs. It directly interacts with the hardware and controls its resources.

[0065] 2) Kernel resources: In this application, they refer to the physical device (i.e., hardware) resources that the operating system kernel can directly access, such as memory, interrupts, DMA channels, etc.

[0066] 3) Dynamic linking technology: refers to the technology that allows the program to find and load (i.e. link) the required library files or other program modules (such as driver modules) at runtime rather than at compile time.

[0067] 4) The interface is the same, but the implementation of the interface is different:

[0068] In this application, the same interface means that in both user mode and kernel mode, the definition parameters of the API interface provided to the driver (for example, the method name, parameter list and return type declared by the API interface, etc.) are the same, thereby unifying the API interface provided to the driver in user mode and kernel mode.

[0069] Different interface implementations mean that the implementation logic provided for the methods declared in the driver API interface is different in user mode and kernel mode.

[0070] For example, the DMA interface parameters provided by the driver API interface for user mode and kernel mode (interface parameters include: source address, destination address, transfer size, request return transfer status field and other information) are the same, but the implementation logic of user mode and kernel mode is different. For example:

[0071] In user mode, the interface implementation logic is to implement DMA operations through a proxy. The implementation method can be as follows: a DMA proxy module is set up in kernel mode. When the user mode driver needs to perform a DMA operation, the DMA request from the driver (including source address, destination address, transfer size and other information) is provided to the DMA proxy module in the operating system kernel. After receiving the request, the DMA proxy module performs the actual DMA operation.

[0072] In kernel mode, the interface implementation logic is to directly execute DMA operations. The implementation method can be as follows: when the kernel mode driver needs to execute DMA operations, the DMA operations are directly executed according to the DMA request from the driver (including source address, destination address, transfer size and other information).

[0073] 5) Device file system: It is a special file system used in the operating system to represent and manage hardware devices. It abstracts physical devices into file form, allowing software to access and control these devices through standard system calls instead of directly operating the hardware interface.

[0074] The driver framework solution provided by the present application can be mounted in different types of operating systems (OS), which have user mode and kernel mode. The solution of the present application sets a driver API interface coupled with the driver module. The specific API interfaces contained in the driver API interface form the API interface layer required for the abstract driver. The API interface for the driver module realizes the unification of the interface in user mode and kernel mode. The present application also provides a user mode implementation of the API interface and a kernel mode implementation of the API interface, so that in these two modes (referring to user mode and kernel mode), different implementation logic is used to respond to the instructions of the driver module received through the API interface, thereby realizing that a set of driver programs provided by the driver module can be reused in user mode and kernel mode, which simplifies the development cost of the driver and shortens the development time compared with the background technology. The solution of the present application is introduced in detail below through various embodiments and drawings.

[0075] The first embodiment of the present application provides a driver framework that can be mounted in different types of OS, which has user mode and kernel mode, such as Figure 1 The schematic diagram of the driving framework shown includes:

[0076] Driver API interface coupled with the driver module;

[0077] The user-mode implementation module of the driver API interface provides a first implementation logic for responding to instructions of the driver module received by the driver API interface when the OS is in user mode;

[0078] The kernel state implementation module of the driver API interface provides a second implementation logic for responding to the instructions of the driver module received by the driver API interface when the OS is in kernel state.

[0079] In some embodiments, the driver module provides drivers for specific hardware in the device. The driver module can be, for example, a driver module for a serial port chip, a driver module for a graphics card, or a driver module for a sound card, etc., to provide serial port drivers, graphics card drivers, or sound card drivers, etc. respectively.

[0080] Among them, the above-mentioned driver API interface refers to the API used to interact with the driver module for information. The API interface includes the specific API interfaces required by the driver module. For example, the specific API interfaces mainly used by the asynchronous receiver and transmitter (UART) driver module may include: receive data interface, send data interface, data arrival notification interface, interrupt registration interface, device space mapping interface, DMA configuration interface, etc.

[0081] In this application, the API interface in user mode and kernel mode is the same, that is, it includes the same specific API interfaces, thereby realizing a set of drivers that can be reused in user mode and kernel mode.

[0082] In some embodiments, as Figure 2 As shown, the driver API interface includes a first type of API interface and a second type of API interface. The first type of API interface is set for accessing non-kernel resources, and the second type of API interface is set for accessing kernel resources. In some embodiments, the first type of API interface is an application-oriented or OS-oriented non-kernel API, for example, it can be an application-oriented or OS-oriented data receiving interface, data sending interface, data arrival notification interface, etc. The instructions transmitted by these API interfaces are all access to non-kernel resources. In some embodiments, the second type of API interface is an OS kernel-oriented API, for example, it can be an interrupt registration interface, a device space mapping interface, a DMA configuration interface, etc. The instructions transmitted by these API interfaces are all access to kernel resources.

[0083] In some embodiments, the first type of API interface includes a dedicated API interface provided by the driver, and the second type of API interface includes a general API interface. Here, the general API interface refers to an API interface that can be provided to various types of drivers; the dedicated API interface refers to an API interface that is only for the specific needs of the current driver (generally related to the hardware corresponding to the driver, such as Figure 6 The API interfaces abstracted from the UART framework API shown in the figure are not API interfaces that every driver will have. The specific API interfaces included are divided into dedicated API interfaces and general API interfaces to quickly understand the characteristics of these specific API interfaces, which facilitates the development process of driver modules and the development process of user-mode implementation modules of the driver API interfaces or kernel-mode implementation modules of the API interfaces.

[0084] In some embodiments, as Figure 3 As shown, the user-mode implementation module of the driver API interface provides the first implementation logic including one of the following:

[0085] 1) With respect to instructions received through the first type of API interface, the operating system or application directly responds to the instructions received through the first type of API interface and performs corresponding operations on non-core resources.

[0086] As mentioned above, the first type of API interface does not have access to kernel resources, and the corresponding instructions received through the first type of API interface do not involve access to kernel resources. Therefore, the operating system or application directly responds to the instructions received by the first type of API interface and performs corresponding operations on non-kernel resources.

[0087] 2) For instructions received through the second type of API interface, the kernel of the operating system responds to the instructions received through the second type of API interface in a proxy manner and performs corresponding operations on kernel resources.

[0088] As mentioned above, the second type of API interface has kernel resource access rights. The corresponding instructions received through the second type of API interface involve access to kernel resources. Due to the limitation of user state permissions, the corresponding operations on kernel resources cannot be directly performed. Therefore, a proxy method can be used to respond to the instructions and perform corresponding operations on kernel resources. The following example illustrates:

[0089] Example 1: In user mode, when a DMA operation instruction is received through the second-class API interface, since DMA operations require privileged permissions and cannot be performed directly in user mode, a proxy method is used as follows: a DMA proxy module is set up in the OS kernel to send the DMA operation request received through the API interface (including information such as the source address, destination address, and transfer size) to the DMA proxy module in the OS kernel. The DMA proxy module verifies the legitimacy of the received DMA request and performs the actual DMA operation. After completing the DMA operation, the DMA proxy module returns the results (such as the transfer status and the amount of data transferred) to the driver. In this way, the driver in user mode can indirectly complete the DMA operation without directly operating the hardware.

[0090] Example 2: Similarly, in user mode, an agent can be used to deliver interrupts to the driver: an interrupt agent module (such as an interrupt handling function) is set up in the OS kernel. The interrupt agent module can have a file descriptor (this file descriptor is used to describe a message or event). After the OS kernel captures the interrupt generated by the hardware, it will update the file descriptor of the interrupt agent module. The interrupt agent module transmits the file descriptor to the driver (or the driver polls the file descriptor). The driver program is informed of the occurrence of the interrupt based on the change in the file descriptor and executes the corresponding interrupt handling logic. In this way, the driver in user mode can indirectly learn that the hardware has generated an interrupt. This method can also be called the interrupt frame simulation method.

[0091] 3) For instructions received through the second type of API interface, the kernel of the operating system responds to the instructions received through the second type of API interface through space mapping and performs corresponding operations on kernel resources. The following examples illustrate:

[0092] For example, in user mode, the operating system can map the physical address of a memory device into the kernel address space, and then further map this portion of the kernel address space into the process address space accessible in user mode. In this way, the process in user mode can indirectly read and write the physical address space of the memory device by reading and writing this portion of the process address space.

[0093] 4) With respect to the instruction received through the second type of API interface, the kernel of the operating system responds to the instruction received through the second type of API interface through a system call, and executes corresponding operations on kernel resources.

[0094] By calling, the processor can temporarily switch between user mode and kernel mode, so as to temporarily switch to kernel mode to perform operations on kernel resources in user mode. The following example illustrates this:

[0095] For example: In user mode, after receiving an instruction, if it is determined that kernel service needs to be requested, a system call is initiated, and the user mode is temporarily switched to kernel mode. The corresponding kernel service is executed in kernel mode, and then the system returns to user mode after the execution is completed.

[0096] In some embodiments, as Figure 4 As shown, the kernel-mode implementation module of the driver API interface provides the second implementation logic including one of the following:

[0097] 1) With respect to instructions received through the first type of API interface, the operating system or application directly responds to the instructions received through the first type of API interface and performs corresponding operations on non-core resources.

[0098] As mentioned above, the first type of API interface does not have access to kernel resources, and the corresponding instructions received through the first type of API interface do not involve access to kernel resources. The operating system or application directly responds to the instructions received by the first type of API interface and performs corresponding operations on non-kernel resources.

[0099] 2) For instructions received through the second type of API interface, the kernel of the operating system directly responds to the instructions received through the driver API interface and directly executes corresponding operations on kernel resources.

[0100] The instructions received through the second type of API interface involve operations on kernel resources. Since it is in kernel state, the corresponding operations on kernel resources are directly executed according to the received instructions.

[0101] In some embodiments, when the driver provided by the driver module is loaded by the user-mode implementation module of the driver API interface or the kernel-mode implementation module of the driver API interface, the driver in binary format is loaded on demand at runtime through dynamic linking technology.

[0102] The binary format driver refers to a binary format that can be directly recognized by a computing device after the driver code is compiled.

[0103] In this application, the driver user-mode implementation module of the API interface or the kernel-mode implementation module of the API interface can load the compiled binary format driver into the OS on demand (when the driver needs to be loaded to access the hardware device corresponding to the driver), and can also be removed from the OS (unloaded) when no longer needed. Figure 5 The schematic diagram of the dynamic driver loading is shown. In user mode, the user mode driver loader dynamically loads the driver as needed. In kernel mode, the kernel mode driver loader dynamically loads the driver as needed.

[0104] In this application, for the driver API implementation, the same set of driver APIs provides two implementations (user state implementation and kernel state implementation). Dynamic linking means decoupling the two driver API implementations from the driver. In user state or kernel state, the required driver binary file can be loaded when needed (such as when the hardware device corresponding to the driver needs to be accessed during program operation). Due to the decoupling, the driver binary file is reused for the user state and kernel state API implementations, and there is no need to compile the driver twice for user state and kernel state respectively, which reduces memory usage. On the other hand, since the API used for running in user state or running in kernel state is the same, the driver can be seamlessly switched to user state and kernel state, that is, the driver can be dynamically linked in user state and kernel state.

[0105] In some embodiments, the above-mentioned driver framework can be used as an independent module, and the device file system can be used to mount the above-mentioned driver framework into different types of OS, so that these OS can communicate with the driver through the driver framework of this application, so that the driver can be applicable to different types of devices and operating systems, thereby improving the versatility and interoperability of the driver.

[0106] To facilitate understanding of the present application, the following further describes a UART driver framework provided in the second embodiment of the present application. The UART driver framework includes a UART driver API interface coupled to a UART driver module, a user-mode implementation module for the UART driver API interface, and a kernel-mode implementation module for the UART driver API interface.

[0107] like Figure 6 As shown in the figure, the UART driver API interface includes: receive data interface, send data interface, data arrival notification interface, interrupt registration interface, device space mapping interface, and DMA configuration interface. The receive data interface, send data interface, and data arrival notification interface are first-class API interfaces, which are used to access non-kernel resources. Figure 6 The UART framework API is marked in the figure. The interrupt registration interface, device space mapping interface, and DMA configuration interface are the second type of API interfaces, which are used to access non-kernel resources. Figure 6 Marked as a common API.

[0108] The user state implementation module of the UART driver API interface provides a first implementation logic for responding to the instructions of the driver module received by the UART driver API interface when the OS is in user state, such as Figure 7A schematic diagram of the first implementation logic is shown. When the driver runs in user mode and accesses kernel resources, interrupts cannot be delivered directly to user mode, making DMA and storage device physical addresses inoperable. Therefore, an interrupt proxy is added to simulate an interrupt frame delivered to user mode in the kernel, and a DMA proxy is added to operate DMA. Furthermore, storage device physical addresses are indirectly manipulated through space mapping. For details, please refer to the corresponding description in the first embodiment and will not be repeated here.

[0109] The kernel state implementation module of the UART driver API interface provides a second implementation logic for responding to the instructions of the driver module received by the UART driver API interface when the OS is in kernel state, such as Figure 8 A schematic diagram of the second implementation logic is shown: When the driver runs in kernel mode, it has full permissions and can directly operate DMA, interrupt storage device physical address and other resources.

[0110] Figure 7 and Figure 8 Also shown is a device manager running in the operating system kernel, which is used to receive registration information of hardware devices and manage the hardware devices.

[0111] The third embodiment of the present application provides a method for processing a driver, which is implemented based on the above-mentioned driver framework. Figure 9 As shown, the method includes:

[0112] S10: receiving instructions from the driver module through the driver API interface;

[0113] S20: When it is determined that the current OS is in user mode, responding to the instruction through the first implementation logic provided by the user mode implementation module of the driver API interface;

[0114] S30: When it is determined that the current OS is in kernel mode, respond to the instruction through the second implementation logic provided by the kernel mode implementation module of the driver API interface.

[0115] Among them, each embodiment of the above-mentioned driving framework can be applied to the processing method and will not be described in detail.

[0116] The fourth embodiment of the present application provides a device for processing a driver, which can be used to implement the above-mentioned method for processing a driver, such as Figure 10 As shown, the device includes:

[0117] The receiving module is used to receive instructions from the driver module through the driver API interface;

[0118] A first processing module is configured to respond to the instruction through a first implementation logic provided by the user-state implementation module of the driver API interface when determining that the current OS is in user state;

[0119] The second processing module is used to respond to the instruction through the second implementation logic provided by the kernel state implementation module of the driver API interface when it is determined that the current OS is in kernel state.

[0120] Figure 11 900 is a schematic structural diagram of a computing device provided in an embodiment of the present application. The computing device can be used as an optional embodiment for implementing the above method. The computing device can be a terminal, or a chip or chip system inside the terminal. Figure 11 As shown, the computing device 900 includes: a processor 910 , a memory 920 , and a communication interface 930 .

[0121] It should be understood that Figure 11 The communication interface 930 in the computing device 900 shown can be used to communicate with other devices, and specifically may include one or more transceiver circuits or interface circuits.

[0122] The processor 910 may be connected to a memory 920. The memory 920 may be used to store the program code and data. Therefore, the memory 920 may be a storage unit within the processor 910, an external storage unit independent of the processor 910, or a component including both a storage unit within the processor 910 and an external storage unit independent of the processor 910.

[0123] Optionally, the computing device 900 may further include a bus. The memory 920 and the communication interface 930 may be connected to the processor 910 via a bus. The bus may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 11 A line without an arrow is used to represent the bus, but this does not mean that there is only one bus or one type of bus.

[0124] It should be understood that in the embodiment of the present application, the processor 910 can adopt a central processing unit (CPU). The processor can also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. Alternatively, the processor 910 adopts one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0125] The memory 920 may include a read-only memory and a random access memory, and provides instructions and data to the processor 910. A portion of the processor 910 may also include a non-volatile random access memory. For example, the processor 910 may also store information about the device type.

[0126] When the computing device 900 is running, the processor 910 executes the computer-executable instructions in the memory 920 to perform any operation step of the above method and any optional embodiment thereof.

[0127] It should be understood that the computing device 900 according to the embodiment of the present application can correspond to the corresponding subject in executing the method according to each embodiment of the present application, and the above-mentioned and other operations and / or functions of each module in the computing device 900 are respectively for implementing the corresponding processes of each method of the present embodiment. For the sake of brevity, they will not be repeated here.

[0128] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0129] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0130] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0131] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0132] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0133] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0134] An embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon. When the program is executed by a processor, the program is used to execute the above method, which includes at least one of the solutions described in the above embodiments.

[0135] The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media.Computer-readable media can be computer-readable signal media or computer-readable storage media.Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or components, or any combination thereof.More specific examples (non-exhaustive list) of computer-readable storage media include: electrical connection with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROMs), optical storage devices, magnetic storage devices, or any suitable combination thereof.In this document, computer-readable storage media can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it.

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

[0137] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0138] The computer program code for performing the operations of the present application can be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer can 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 can be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0139] In addition, the words "first, second, third, etc." or module A, module B, module C and other similar terms in the specification and claims are only used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that the specific order or sequence can be interchanged where permitted so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0140] In the above description, the numbers representing the steps, such as S110, S120, etc., do not necessarily mean that the steps must be executed in this manner. If permitted, the order of the steps can be interchanged or they can be executed simultaneously.

[0141] The term "comprising" as used in the specification and claims should not be construed as limiting to what is listed thereafter; it does not exclude other elements or steps. Thus, it should be interpreted as specifying the presence of the features, integers, steps, or components mentioned, but not excluding the presence or addition of one or more other features, integers, steps, or components, or groups thereof. Thus, the expression "a device comprising means A and B" should not be limited to a device consisting solely of components A and B.

[0142] References in this specification to "one embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present application. Therefore, the phrases "in one embodiment" or "in an embodiment" appearing throughout this specification do not necessarily refer to the same embodiment, but may refer to the same embodiment. Furthermore, in one or more embodiments, the particular features, structures, or characteristics can be combined in any suitable manner, as would be apparent to one of ordinary skill in the art from this disclosure.

[0143] Note that the above are only preferred embodiments of the present application and the technical principles employed. Those skilled in the art will understand that the present application is not limited to the specific embodiments described herein, and that various obvious changes, readjustments, and substitutions can be made by those skilled in the art without departing from the scope of protection of the present application. Therefore, although the present application has been described in more detail through the above embodiments, the present application is not limited to the above embodiments and may include many other equivalent embodiments without departing from the scope of protection of the present application, all of which fall within the scope of protection of the present application.

Claims

1. A driving framework, characterized in that: Can be mounted on different types of OS. The driver framework includes: Driver API interface coupled with the driver module; The user-mode implementation module of the driver API interface provides a first implementation logic for responding to instructions of the driver module received by the driver API interface when the OS is in user mode; The kernel state implementation module of the driver API interface provides a second implementation logic for responding to the instructions of the driver module received by the driver API interface when the OS is in kernel state.

2. The driving frame according to claim 1, characterized in that: The driver API interface includes a first type of API interface and a second type of API interface. The first type of API interface is set to access non-kernel resources, and the second type of API interface is set to access kernel resources.

3. The driving frame according to claim 2, characterized in that: The user-mode implementation module driving the API interface provides the first implementation logic including one of the following: For instructions received through the first type of API interface, the operating system or application directly responds to the instructions received through the first type of API interface and performs corresponding operations on non-core resources; For instructions received through the second type of API interface, the kernel of the operating system responds to the instructions received through the second type of API interface in a proxy manner and performs corresponding operations on kernel resources; For instructions received through the second type of API interface, the kernel of the operating system responds to the instructions received through the second type of API interface in a spatial mapping manner and performs corresponding operations on kernel resources; For the instructions received through the second type of API interface, the kernel of the operating system responds to the instructions received through the second type of API interface through a system call and executes corresponding operations on kernel resources.

4. The driving frame according to claim 2, characterized in that: The kernel-mode implementation module of the driver API interface provides the second implementation logic including one of the following: For instructions received through the first type of API interface, the operating system or application directly responds to the instructions received through the first type of API interface and performs corresponding operations on non-core resources; For instructions received through the second type of API interface, the kernel of the operating system directly responds to the instructions received through the driver API interface and performs corresponding operations on kernel resources.

5. The driving frame according to claim 1, characterized in that: When the driver provided by the driver module is loaded by the user-mode implementation module of the driver API interface or the kernel-mode implementation module of the driver API interface, the driver in binary state is loaded on demand at runtime through dynamic linking technology.

6. A method for processing a driver, characterized in that: Based on the driving framework according to any one of claims 1 to 5, the method includes: Receive instructions from the driver module through the driver API interface; When it is determined that the current OS is in user mode, responding to the instruction through the first implementation logic provided by the user mode implementation module of the driver API interface; When it is determined that the current OS is in kernel mode, the instruction is responded to through the second implementation logic provided by the kernel mode implementation module of the driver API interface.

7. The method according to claim 6, characterized in that The driver API interface includes a first type of API interface and a second type of API interface, the first type of API interface is set to be used for accessing non-kernel resources, and the second type of API interface is set to be used for accessing kernel resources; The user-mode implementation module driving the API interface provides the first implementation logic including one of the following: For instructions received through the first type of API interface, the operating system or application directly responds to the instructions received through the first type of API interface and performs corresponding operations on non-core resources; For instructions received through the second type of API interface, the kernel of the operating system responds to the instructions received through the second type of API interface in a proxy manner and performs corresponding operations on kernel resources; For instructions received through the second type of API interface, the kernel of the operating system responds to the instructions received through the second type of API interface in a spatial mapping manner and performs corresponding operations on kernel resources; For instructions received through the second type of API interface, the kernel of the operating system responds to the instructions received through the second type of API interface through a system call and performs corresponding operations on kernel resources; The kernel-mode implementation module of the driver API interface provides the second implementation logic including one of the following: For instructions received through the first type of API interface, the operating system or application directly responds to the instructions received through the first type of API interface and performs corresponding operations on non-core resources; For instructions received through the second type of API interface, the kernel of the operating system directly responds to the instructions received through the driver API interface and performs corresponding operations on kernel resources.

8. A device for processing a drive, characterized in that: include: The receiving module is used to receive instructions from the driver module through the driver API interface; A first processing module is configured to respond to the instruction through a first implementation logic provided by the user-state implementation module of the driver API interface when determining that the current OS is in user state; The second processing module is used to respond to the instruction through the second implementation logic provided by the kernel state implementation module of the driver API interface when it is determined that the current OS is in kernel state.

9. A computing device, characterized in that include: processor, and A memory having program instructions stored thereon, wherein when the program instructions are executed by the processor, the processor executes the drive processing method according to claim 6 or 7.

10. A computer-readable storage medium, characterized in that Program instructions are stored thereon, and when the program instructions are executed by a computer, the computer is caused to execute the method for processing drive according to claim 6 or 7.

Images