Driving framework, processing method and device thereof

Abstract

The application relates to a driving framework which can be mounted in different types of OSs, the driving framework comprising: a driving API interface coupled with a driving module; a user state implementation module of the driving API interface, which provides first implementation logic for responding to instructions of the driving module received by the driving API interface when the OS is in a user state; and a kernel state implementation module of the driving API interface, which provides second implementation logic for responding to instructions of the driving module received by the driving API interface when the OS is in a kernel state. The application can simplify development of a driving program and realize that one set of driving programs can be applied to a kernel state and a user state.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a driver framework, a method and apparatus for processing drivers, a computing device and a storage medium. Background Technology

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

[0003] A driver, as a special type of software program, acts as a bridge between hardware and the operating system, enabling data transfer between the two. The main function of a driver is to allow the operating system to recognize, configure, manage, and control hardware devices, ensuring that the hardware devices function properly and work in conjunction with corresponding applications within the operating system. For example, a driver provides the operating system with a set of application programming interfaces (APIs), through which the operating system or applications can perform read / write operations and control operations on the hardware devices. Furthermore, hardware devices typically use interrupts to notify the operating system of specific events (such as data readiness or error occurrence), and drivers need to register and handle these interrupts, responding promptly to changes in device state.

[0004] Currently, for security reasons, operating systems provide kernel mode and user mode. A brief overview is as follows:

[0005] Kernel mode: Also known as privileged mode or superuser 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. All types of instructions can be executed in kernel mode, including privileged instructions.

[0006] User mode: This refers to the running mode of ordinary applications, also known as non-privileged mode. Programs running in user mode are subject to strict permission restrictions; they cannot directly access arbitrary areas of memory or directly manipulate hardware devices. When an application needs to perform operations involving system resources, such as reading and writing to disk, creating processes, or network communication, it can switch to kernel mode (if permitted), or receive instructions through an agent in the operating system kernel (which is always in kernel mode), verify them, and then execute the relevant operations.

[0007] Currently, driver development for kernel mode involves directly matching the kernel interface (referring to the operating system kernel's API), and this can be called a kernel-mode driver. Kernel-mode drivers typically cannot run directly in user mode because they need to access and control low-level hardware resources. These operations involve direct manipulation and sensitive operations of core system resources, requiring high privilege levels. User-mode programs, running at relatively lower privilege levels, require restricted direct access to hardware resources for system security and isolation reasons; therefore, kernel-mode drivers cannot be used directly in user mode. Thus, for user mode, a new driver needs to be developed, which can be called a user-mode driver. For example, a user-mode driver can be developed based on the UIO (Userspace I / O) or VFIO (Virtual Function I / O) interface framework used in user mode.

[0008] Users may have different needs for different scenarios. For example, some users may want the operating system to be in kernel mode because, while kernel mode offers lower security (meaning providing kernel-level privileges to users), it offers higher performance. Conversely, some users may want the operating system to be in user mode because it offers higher security (meaning providing only user-level privileges to users). Therefore, users will switch the operating system between kernel mode and user mode based on their specific needs.

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

[0010] Therefore, in this context, how to provide a solution to simplify driver development and enable the use of a single driver that can be applied to both 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-mentioned problems of the prior art, this application provides a driver framework, a method and apparatus for processing drivers, a computing device and a storage medium, so as to simplify the development of drivers and enable the use of a single driver that can be applied to both kernel mode and user mode.

[0012] To achieve the above objectives, the first aspect of this application provides a driver framework that can be mounted on different types of operating systems, the driver framework comprising:

[0013] The 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 the instructions of the driver module received by the driver API interface when the OS is in user mode.

[0015] The kernel-mode 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 mode.

[0016] As described above, this application achieves a unified API interface for drivers in both user space and kernel space. This allows a single driver to be reused in both kernel and user space, simplifying the driver development process, eliminating repetitive driver development work, shortening the development cycle, and reducing development costs. Furthermore, the driver framework of this application decouples the driver component from the API component, enhancing the flexibility of driver development.

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

[0018] As described above, classifying the driver API interfaces makes it easier to set different implementation logic for different types of API interfaces.

[0019] As one possible implementation of the first aspect, the user-space implementation module that drives the API interface provides the first implementation logic including one of the following:

[0020] In response 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-kernel resources;

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

[0022] In response to instructions received through the second type of API interface, the operating system kernel responds to the instructions received through the second type of API interface by means of space mapping, and performs corresponding operations on kernel resources;

[0023] In response to instructions received through the second type of API interface, the operating system kernel responds to the instructions received through the second type of API interface via system calls, and performs corresponding operations on kernel resources.

[0024] Based on the above, specific logic can be flexibly selected for the first implementation logic in user mode to achieve access to kernel resources in user mode.

[0025] As one 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] In response 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-kernel resources;

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

[0028] As one possible implementation of the first aspect, 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.

[0029] As shown above, through dynamic linking technology, it is possible to load the required driver binary file when needed (such as when the program needs to access the hardware device corresponding to the driver during operation) in user mode or kernel mode.

[0030] A second aspect of this application provides a method for processing drivers, based on any of the driver frameworks 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, the instruction is responded to 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 one 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 configured for accessing non-kernel resources, and the second type of API interface is configured for accessing kernel resources.

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

[0036] In response 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-kernel resources;

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

[0038] In response to instructions received through the second type of API interface, the operating system kernel responds to the instructions received through the second type of API interface by means of space mapping, and performs corresponding operations on kernel resources;

[0039] In response to instructions received through the second type of API interface, the operating system kernel responds to the instructions received through the second type of API interface via system calls, and performs corresponding operations on kernel resources;

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

[0041] In response 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-kernel resources;

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

[0043] A third aspect of this application provides a processing apparatus for a drive, comprising:

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

[0045] The first processing module is used to respond to the instruction through the first implementation logic provided by the user-mode implementation module of the driver API interface when the current OS is in user mode.

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

[0047] A fourth aspect of this application provides a computing device, including: a communication interface and at least one processor; wherein the at least one processor is configured to execute program instructions, which, when executed by the at least one processor, cause the computing device to perform the method described above.

[0048] The fifth aspect of this application provides a computer-readable storage medium having program instructions stored thereon, which, when executed by a computer, cause the computer to perform the above-described method. Attached Figure Description

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

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

[0051] Figure 3 This is a schematic diagram of the user-space implementation module of the driver API interface provided in the embodiments of this application;

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

[0053] Figure 5 This is a schematic diagram illustrating the dynamic loading of drivers in user mode and kernel mode provided in the embodiments of this application;

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

[0055] Figure 7 This is a schematic diagram of the user-space implementation module of the UART driver API interface provided in the embodiments of this application;

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

[0057] Figure 9 This is a flowchart of the driver processing method provided in the embodiments of this application;

[0058] Figure 10 This is a flowchart of the driving processing device provided in the embodiments of this application;

[0059] Figure 11 This is a schematic structural diagram of a computing device provided in an embodiment of this application.

[0060] It should be understood that the dimensions 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 only schematic representations of the structural relationships between the blocks, and are not intended to limit the physical connection methods of the embodiments of the present invention. Detailed Implementation

[0061] The technical solutions provided in this application will be further described below with reference to the accompanying drawings and embodiments. It should be understood that the system architecture and business scenarios provided in the embodiments of this application are mainly for illustrating possible implementations of the technical solutions of this application and should not be construed as the sole limitation on the technical solutions of this application. Those skilled in the art will recognize that the technical solutions provided in this application are equally applicable to similar technical problems as system architectures evolve and new business scenarios emerge.

[0062] It should be understood that the driver framework solution provided in this application includes a driver framework, a method and apparatus for processing the driver, a computing device, and a storage medium. Since these technical solutions solve problems based on the same or similar principles, some repetitions may not be repeated in the following description of specific embodiments, but it should be considered that these specific embodiments have mutual references and can be combined with each other.

[0063] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. In case of any inconsistency, the meaning set forth in this specification or derived from the content described herein shall prevail. Furthermore, the terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application. To accurately describe the technical content of this application and to accurately understand the invention, the following explanations or definitions of the terms used in this specification are provided before describing specific embodiments:

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

[0065] 2) Kernel resources: In this application, it refers to 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 a 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) Same interface, different implementations:

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

[0069] The difference in interface implementation means 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 for both user space and kernel space (interface parameters include, for example, source address, destination address, transfer size, and request return transfer status fields) are the same, but the implementation logic in user space and kernel space is different.

[0071] In user space, the interface implementation logic is to perform DMA operations through a proxy. The implementation method can be as follows: set up a DMA proxy module in kernel space. When the user space driver needs to perform a DMA operation, it provides the DMA request from the driver (including source address, destination address, transfer size, etc.) 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 implementation logic of this interface is to directly execute DMA operations. The implementation method can be as follows: when the kernel mode driver needs to execute a DMA operation, it directly executes the DMA operation based on the DMA request from the driver (including information such as source address, destination address, and transfer size).

[0073] 5) Device file system: This is a special file system in the operating system used 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, rather than directly manipulating the hardware interface.

[0074] The driver framework solution provided in this application can be mounted on different types of operating systems (OS), which have user mode and kernel mode. The solution of this application sets up a driver API interface coupled with the driver module. The various specific API interfaces contained in this driver API interface form the API interface layer required by the abstract driver. The API interface for the driver module is unified in both user mode and kernel mode. This application also provides both user-mode and kernel-mode implementations of the API interface, so that different implementation logic can be used to respond to the instructions received from the driver module through the API interface in these two modes (user mode and kernel mode). This enables a single driver program provided by the driver module to be reused in both user mode and kernel mode, simplifying driver development costs and shortening development time compared to the prior art. The solution of this application will be described in detail below through various embodiments and accompanying drawings.

[0075] The first embodiment of this application provides a driver framework that can be mounted on different types of operating systems, such as user mode and kernel mode. Figure 1 The schematic diagram of the driving framework shown includes:

[0076] The 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 the instructions of the driver module received by the driver API interface when the OS is in user mode.

[0078] The kernel-mode 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 mode.

[0079] In some embodiments, the driver module provides drivers for specific hardware in the device. For example, the driver module may be 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] The aforementioned driver API interface refers to the API used for information interaction with the driver module. This API interface includes all the specific API interfaces required by the driver module. For example, the specific API interfaces mainly used by the asynchronous transceiver (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 is the same in both user mode and kernel mode, that is, it includes the same specific API interfaces, thereby realizing the reuse of a set of drivers in user mode and kernel mode.

[0082] In some embodiments, such 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 configured for accessing non-kernel resources, and the second type of API interface is configured for accessing kernel resources. In some embodiments, the first type of API interface is an application-oriented or OS non-kernel API, such as an application-oriented or OS-oriented data receiving interface, data sending interface, data arrival notification interface, etc., and the instructions transmitted by these API interfaces are all for accessing non-kernel resources. In some embodiments, the second type of API interface is an OS kernel-oriented API, such as an interrupt registration interface, device space mapping interface, DMA configuration interface, etc., and the instructions transmitted by these API interfaces are all for accessing kernel resources.

[0083] In some embodiments, the first type of API interface includes dedicated API interfaces provided by the driver, and the second type of API interface includes general-purpose API interfaces. Here, general-purpose API interfaces refer to API interfaces that can be provided to various types of drivers; dedicated API interfaces refer to interfaces specific to the current driver's needs (generally related to the hardware corresponding to the driver, for example...). Figure 6 The API interfaces shown are abstracted from the UART framework API, and not every driver will have them. Distinguishing between dedicated and general API interfaces is to quickly understand their characteristics, which is beneficial for the development of driver modules, as well as for the development of user-mode or kernel-mode implementations of the driver API interfaces.

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

[0085] 1) 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-kernel resources.

[0086] As mentioned earlier, the first type of API interface does not have access to kernel resources. 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 through 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 operating system kernel responds to the instructions received through the second type of API interface through a proxy and performs corresponding operations on kernel resources.

[0088] As mentioned earlier, the second type of API interface has kernel resource access permissions. The corresponding instructions received through this second type of API interface involve access to kernel resources. Due to user-mode permission restrictions, direct operation on kernel resources is not possible. Therefore, a proxy method can be used to respond to these instructions and perform corresponding operations on kernel resources. An example is given below:

[0089] Example 1: In user space, when a DMA operation instruction is received through a type-two API interface, since DMA operations require privileged permissions and cannot be performed directly in user space, a proxy approach is used to perform the DMA operation: A DMA proxy module is set up in the OS kernel, which sends the DMA operation request received through the API interface (including source address, destination address, transfer size, etc.) to the OS kernel's DMA proxy module. The DMA proxy module verifies the validity of the received DMA request and executes the actual DMA operation. After completing the DMA operation, the DMA proxy module returns the result (such as transfer status, amount of data transferred, etc.) to the driver. In this way, the driver in user space can indirectly complete the DMA operation without directly manipulating the hardware.

[0090] Example 2: Similarly, in user space, interrupts can be delivered to the driver using a proxy: An interrupt proxy module (e.g., an interrupt handler function) is set up in the OS kernel. This interrupt proxy module may have a file descriptor (used to describe a message or event). After the OS kernel captures an interrupt generated by the hardware, it updates the file descriptor of the interrupt proxy module. The interrupt proxy module transmits the file descriptor to the driver (or the driver polls the file descriptor). The driver program learns of the interrupt occurrence based on the change in the file descriptor and executes the corresponding interrupt handling logic. In this way, the driver in user space can indirectly learn of hardware interrupts; this method can also be called interrupt frame emulation.

[0091] 3) For instructions received through the second type of API interface, the operating system kernel responds to the instructions through space mapping, performing corresponding operations on kernel resources. An example is given below:

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

[0093] 4) In response to instructions received through the second type of API interface, the operating system kernel responds to the instructions received through the second type of API interface by means of system calls, and performs corresponding operations on kernel resources.

[0094] By invoking, the processor can temporarily switch between user mode and kernel mode, allowing it to temporarily switch to kernel mode to perform operations on kernel resources that were in user mode. The following example illustrates this:

[0095] For example, in user mode, after receiving an instruction, if it is determined that a kernel service needs to be requested, a system call is initiated, temporarily switching from user mode to kernel mode, executing the corresponding kernel service in kernel mode, and then returning to user mode after execution.

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

[0097] 1) 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-kernel resources.

[0098] As mentioned above, the first type of API interface does not have access to kernel resources. 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 through 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 operating system kernel directly responds to the instructions received through the driver API interface and directly performs the corresponding operations on kernel resources.

[0100] Instructions received through the second type of API interface involve operations on kernel resources. Since the system is in kernel mode, the corresponding operations on kernel resources are executed directly 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 binary format driver is loaded on demand at runtime through dynamic linking technology.

[0102] Among them, binary format drivers refer to binary format drivers that are compiled into a form that can be directly recognized by computing devices.

[0103] In this application, either the user-mode implementation module of the API interface driver or the kernel-mode implementation module of the API interface driver can load the compiled binary driver into the OS as needed (when the driver needs to be loaded to access the hardware device corresponding to the driver), and can also remove it from the OS when it is no longer needed. Figure 5 The diagram illustrates the dynamic driver loading mechanism. In user mode, the driver is dynamically loaded as needed by the user-mode driver loader, and in kernel mode, the driver is dynamically loaded as needed by the kernel-mode driver loader.

[0104] In this application, for the driver API implementation, the same set of driver APIs provides two implementations (user-mode implementation and kernel-mode implementation). Dynamic linking means decoupling the two driver API implementations from the driver. In user mode or kernel mode, the required driver binary file can be loaded when needed (such as when the program needs to access the hardware device corresponding to the driver during runtime). Due to this decoupling, the driver binary file can be reused for both user-mode and kernel-mode API implementations, eliminating the need to compile the driver twice for user mode and kernel mode, thus reducing memory consumption. On the other hand, since the API used when running in user mode or kernel mode is the same, the driver can be seamlessly switched between user mode and kernel mode, that is, the driver can be dynamically linked in both user mode and kernel mode.

[0105] In some embodiments, the driver framework described above can be used as an independent module. The driver framework can be mounted to different types of operating systems using a device file system, so that these operating systems can communicate with the driver through the driver framework of this application, thereby making the driver applicable to different types of devices and operating systems, improving the versatility and interoperability of the driver.

[0106] To facilitate understanding of this application, a UART driver framework provided in the second embodiment of this application will be further described below. This UART driver framework includes a UART driver API interface coupled to a UART driver module, a user-mode implementation module of the UART driver API interface, and a kernel-mode implementation module of the UART driver API interface.

[0107] like Figure 6 As shown, the UART driver API interface includes: receive data interface, transmit data interface, data arrival notification interface, interrupt registration interface, device space mapping interface, and DMA configuration interface. Among these, the receive data interface, transmit data interface, and data arrival notification interface are the first type of API interface, used for accessing non-kernel resources. Figure 6 The API is labeled as the UART framework API. Among them, the interrupt registration interface, device space mapping interface, and DMA configuration interface are classified as second-type API interfaces, used for accessing non-kernel resources. Figure 6 It is marked as a general API.

[0108] The user-mode implementation module of the UART driver API interface provides the first implementation logic for responding to instructions from the driver module received by the UART driver API interface when the OS is in user mode, such as... Figure 7A schematic diagram of the first implementation logic is shown: When the driver runs in user mode, when accessing kernel resources, since interrupts cannot be directly delivered to user mode, DMA cannot be operated, and the physical address of the storage device cannot be directly operated. Therefore, an interrupt proxy is added to simulate an interrupt frame in the kernel and deliver it to user mode, and DMA is operated by adding a DMA proxy, as well as indirectly operating the physical address of the storage device through space mapping. For details, please refer to the corresponding description in the first embodiment, which will not be repeated here.

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

[0110] Figure 7 and Figure 8 The document also shows the device manager running in the operating system kernel, which is used to receive and manage hardware devices.

[0111] The third embodiment of this application provides a method for processing drivers, implemented based on the aforementioned driver framework, such as... Figure 9 As shown, the method includes:

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

[0113] S20: When it is determined that the current OS is in user mode, respond 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] The various embodiments of the aforementioned driving framework can be applied to this processing method, and will not be described in detail here.

[0116] The fourth embodiment of this application provides a driver processing apparatus that can be used to implement the above-described driver processing method, 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] The first processing module is used to respond to the instruction through the first implementation logic provided by the user-mode implementation module of the driver API interface when the current OS is in user mode.

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

[0120] Figure 11 This is a schematic structural diagram of a computing device 900 provided in an embodiment of this application. This computing device can be an optional embodiment for implementing the above-described method; it can be a terminal, or a chip or chip system within 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 may specifically include one or more transceiver circuits or interface circuits.

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

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

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

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

[0126] When the computing device 900 is running, the processor 910 executes computer execution instructions stored in the memory 920 to perform any of the operational steps of the above method and any of the optional embodiments thereof.

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

[0128] Those skilled in the art will recognize that the units and algorithm steps of the various examples 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 implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art 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 understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing 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, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0131] The units described as separate components may or may not be physically separate. 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 the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0132] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0133] If the aforementioned functions are implemented as 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 this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0134] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is used to perform the above-described method, which includes at least one of the schemes described in the above embodiments.

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

[0136] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying 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. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0137] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0138] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and 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 standalone 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 remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

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

[0140] In the above description, the labels of the steps involved, such as S110, S120, etc., do not mean that the steps will necessarily be executed. The order of the steps can be interchanged or executed simultaneously if permitted.

[0141] The term "comprising" as used in the specification and claims should not be construed as limiting itself to what follows; it does not exclude other elements or steps. Therefore, it should be interpreted as specifying the presence of the mentioned feature, integral, step, or component, but does not exclude the presence or addition of one or more other features, integrals, steps, or components, or groups thereof. Thus, the statement "device comprising means A and B" should not be limited to a device consisting solely of components A and B.

[0142] The terms "an embodiment" or "an embodiment" as used in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in at least one embodiment of this application. Therefore, the terms "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 will be apparent to those skilled in the art from this disclosure.

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

Claims

1. A driving framework, characterized in that, The driver framework can be mounted on different types of operating systems and includes: The 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 the instructions of the driver module received by the driver API interface when the OS is in user mode. The kernel-mode 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 mode. 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 configured for accessing non-kernel resources, and the second type of API interface is configured for accessing kernel resources. The user-space implementation module of the driver API interface provides the first implementation logic, which includes one of the following: In response 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-kernel resources; In response to instructions received through the second type of API interface, the operating system kernel responds to the instructions received through the second type of API interface via a proxy, and performs corresponding operations on kernel resources; In response to instructions received through the second type of API interface, the operating system kernel responds to the instructions received through the second type of API interface by means of space mapping, and performs corresponding operations on kernel resources; In response to instructions received through the second type of API interface, the operating system kernel responds to the instructions received through the second type of API interface via system calls, and performs corresponding operations on kernel resources.

2. The driving framework according to claim 1, characterized in that, The kernel-mode implementation module of the driver API interface provides the second implementation logic, which includes one of the following: In response 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-kernel resources; In response to instructions received through the second type of API interface, the operating system kernel directly responds to the instructions received through the driver API interface and performs corresponding operations on kernel resources.

3. The driving framework according to claim 1, characterized in that, When the driver provided by the driver module is loaded by the user-mode implementation module 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.

4. A method for processing drives, characterized in that, Based on the driving framework according to any one of claims 1-3, 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, the instruction is responded to 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; 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 configured for accessing non-kernel resources, and the second type of API interface is configured for accessing kernel resources. The user-space implementation module of the driver API interface provides the first implementation logic including one of the following: In response 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-kernel resources; In response to instructions received through the second type of API interface, the operating system kernel responds to the instructions received through the second type of API interface via a proxy, and performs corresponding operations on kernel resources; In response to instructions received through the second type of API interface, the operating system kernel responds to the instructions received through the second type of API interface by means of space mapping, and performs corresponding operations on kernel resources; In response to instructions received through the second type of API interface, the operating system kernel responds to the instructions received through the second type of API interface via system calls, and performs corresponding operations on kernel resources.

5. The method according to claim 4, characterized in that, The kernel-mode implementation module of the driver API interface provides the second implementation logic, which includes one of the following: In response 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-kernel resources; In response to instructions received through the second type of API interface, the operating system kernel directly responds to the instructions received through the driver API interface and performs corresponding operations on kernel resources.

6. A processing device for a drive, characterized in that, include: The receiving module is used to receive instructions from the driver module through the driver API interface; The first processing module is used to respond to the instruction through the first implementation logic provided by the user-mode implementation module of the driver API interface when the current OS is in user mode. The second processing module is used to respond to the instruction through the second implementation logic provided by the kernel-mode implementation module of the driver API interface when the current OS is in kernel mode. 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 configured for accessing non-kernel resources, and the second type of API interface is configured for accessing kernel resources. The user-space implementation module of the driver API interface provides the first implementation logic, which includes one of the following: In response 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-kernel resources; In response to instructions received through the second type of API interface, the operating system kernel responds to the instructions received through the second type of API interface via a proxy, and performs corresponding operations on kernel resources; In response to instructions received through the second type of API interface, the operating system kernel responds to the instructions received through the second type of API interface by means of space mapping, and performs corresponding operations on kernel resources; In response to instructions received through the second type of API interface, the operating system kernel responds to the instructions received through the second type of API interface via system calls, and performs corresponding operations on kernel resources.

7. A computing device, characterized in that, include: processor, and A memory storing program instructions that, when executed by the processor, cause the processor to perform the processing method for the driver as described in claim 4 or 5.

8. A computer-readable storage medium, characterized in that, It stores program instructions that, when executed by a computer, cause the computer to perform the driver processing method as described in claim 4 or 5.

Images