Driving framework, operating system, driving program calling method and electronic device

Abstract

Embodiments of the present application provide a driving framework, an operating system, a calling method of a driving program and an electronic device, wherein the driving framework comprises an inter-process communication interface layer and a driving core layer; the driving core layer comprises a distribution module and a processing module, the processing module comprises an IO function processing module and a pulse function processing module; wherein: the distribution module is configured to receive request information from a client and distribute the request information to the processing module; the processing module is configured to process the request information and call an operation function of the driving program through the inter-process communication interface layer to access a device corresponding to the driving program. In the present application, the processing module is set under the driving framework, the request information can be parsed, the integrity of the inter-kernel communication data transmission is ensured, and finally the specific IO function type is parsed, so that a set of IO functions adapted to the driving framework is avoided to be configured in the driving program, and the development complexity of the driving program is reduced.

Description

Technical Field

[0001] This application relates to the fields of computer and Internet technology, and in particular to driver frameworks, operating systems, methods for calling drivers, and electronic devices. Background Technology

[0002] Microkernel operating systems retain some core functionalities within the kernel, while other functions are moved to user space and interact as service processes. The driver framework, an important function outside the kernel, is integrated as a library into various user processes and driver processes. The driver framework abstracts the common parts from drivers for the same type of hardware across different models, leaving only the different parts for specific driver developers to implement. Therefore, the driver framework needs to ensure as much functionality as possible and be compatible with various types of devices. At the same time, the design of the driver framework should be as standardized as possible to facilitate development or porting by driver developers, reducing the difficulty and workload of driver development.

[0003] Currently, the driver framework of microkernel operating systems requires each driver to adapt to a set of I / O operation functions, which increases the difficulty of driver development. Summary of the Invention

[0004] This application provides a driver framework, an operating system, a method for calling a driver, and an electronic device, which provides a driver framework to reduce the difficulty of driver development.

[0005] In a first aspect, this application provides a driver framework, including: an inter-process communication interface layer and a driver core layer; the driver core layer includes: a distribution module and a processing module, the processing module including: an IO function processing module and a pulse function processing module; wherein: the distribution module is used to receive request information from the client and distribute the request information to the processing module; the processing module is used to process the request information and call the operation function of the driver through the inter-process communication interface layer to access the device corresponding to the driver.

[0006] Secondly, this application provides a method for invoking a driver, applied to the driver framework of the first aspect. The method for invoking a driver includes:

[0007] The distribution module receives request information sent by the client; the distribution module distributes the request information to the processing module; the processing module processes the information type and content of the request information, and after deserialization and adaptation to the driver's operation functions through the inter-process communication interface layer, it calls the driver's operation functions to access the device corresponding to the driver.

[0008] In one possible implementation, the processing module includes an I / O function processing module. The processing module calls the driver's operation function based on the request information, including: the I / O function processing module calls the deserialization function of the inter-process communication interface layer according to the information type and content of the request information; adapts the driver's operation function based on the deserialization function, and then calls the driver's operation function.

[0009] In one possible implementation, before the distribution module receives the request information sent by the client, the following steps are also included: providing a registration interface to the driver during driver initialization, so that the driver can call the registration interface to register; requesting an inter-process communication channel from the kernel using the driver core layer, so that the kernel can establish a data transmission channel and allocate an inter-process communication channel number to the data transmission channel; registering the path name and inter-process communication channel number with the pathname manager using the driver core layer; and requesting resources and starting the service using the driver core layer.

[0010] In one possible implementation, a distribution module is used to receive request information sent by the client, including: when the client obtains the inter-process communication channel number from the path name manager based on the path name, the distribution module receives the request information sent by the client based on the inter-process communication channel number.

[0011] Thirdly, this application provides an operating system, which includes the driver framework of the first aspect. The operating system further includes: a kernel, an I / O layer, an operating system interface layer, a driver, and a pathname manager, wherein: the operating system interface layer is used to receive function call information sent by the client; the I / O layer encapsulates the function call information into a request message in the kernel's inter-process communication information format based on the inter-process communication interface layer, and sends the request message to the driver kernel layer of the driver framework through the kernel's inter-process communication; the driver framework is used to call the operation function of the driver based on the request message; the driver is used to access the device corresponding to the driver based on the operation function; the driver framework is also used to register relevant information of the driver with the pathname manager, the relevant information including: path name and inter-process communication channel number.

[0012] Fourthly, this application provides a method for invoking a driver, applied to the operating system of the third aspect. The method for invoking a driver includes: after the driver completes the registration of its operation functions, it starts the service of the driver process; the driver core layer receives request information sent by the client through the kernel's inter-process communication; the driver core layer processes the request information and calls the operation functions of the driver through the inter-process communication interface layer to access the device corresponding to the driver.

[0013] Fifthly, this application provides an electronic device, including: at least one processor and a memory;

[0014] The memory stores the instructions that the computer executes;

[0015] At least one processor executes computer execution instructions stored in memory, causing at least one processor to execute the driver invocation method as described in the first or third aspect above.

[0016] Sixthly, this application provides a computer-readable storage medium storing an instruction executed by a computer, which, when executed by a processor, implements the driver invocation method described in the first or third aspect above.

[0017] In a seventh aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the driver invocation method as described in the first or third aspect.

[0018] This application provides a driver framework, operating system, driver invocation method, and electronic device. The driver framework includes an inter-process communication interface layer and a driver core layer. The driver core layer includes a dispatch module and a processing module. The processing module includes an I / O function processing module and a pulse function processing module. The dispatch module receives request information from the client and dispatches it to the processing module. The processing module processes the request information and calls the driver's operation functions through the inter-process communication interface layer to access the device corresponding to the driver. By setting up a processing module within the driver framework, this application can parse the request information, ensure the integrity of data transmission in inter-kernel communication, and finally parse out the specific I / O function type. This avoids configuring a set of I / O functions adapted to the driver framework in the driver, reducing the development complexity of the driver. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A schematic diagram of the operating system for the related technology;

[0021] Figure 2 A schematic diagram of the operating system provided in the embodiments of this application;

[0022] Figure 3 A flowchart illustrating the steps of a driver invocation method provided in an optional embodiment of this application;

[0023] Figure 4 A flowchart illustrating the steps of a driver invocation method provided in another optional embodiment of this application;

[0024] Figure 5 An example flowchart of a driver invocation method provided for an optional embodiment of this application;

[0025] Figure 6 A schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] The vehicle control operating system is primarily QNX Neutrino (Fast Real-Time Operating System). QNX Neutrino is a microkernel operating system. Figure 1 This diagram illustrates the structural block diagram of QNX Neutrino in related technologies. The operating system 10 includes: a resource manager 11, a driver 12, a pathname manager 13, a Portable Operating System Interface (POSIX) layer 14, an I / O layer, and a kernel. The resource manager 11 is a server that manages "resources," which can be hardware, services, or even a file directory. The resource manager is the core of the QNX driver framework. Developing the QNX driver framework requires three steps: 1) Creating the resource manager and registering the device's path name (e.g., for serial port 1, the path name can be set to / dev / ser1) with the pathname manager, allowing users to operate the device as a file, thus controlling or accessing the device. Figure 1 1) The register module in the driver; 2) For each I / O interface supported by the driver process and called by the user process, the corresponding I / O operation function needs to be implemented in the driver to ensure that the client can perform the corresponding operation when calling the POSIX interface. Figure 1 The driver program includes various io_xx functions, such as open, read, write, close, etc.; 3) It implements specific hardware operations such as device read / write configuration, corresponding to... Figure 1 The operations section of the driver.

[0028] Furthermore, clients can access the driver process's devices (including hardware or virtual devices) through standard POSIX interfaces in the form of file operations. This process involves inter-process communication within the kernel. QNX predefines the information types and formats that need to be transmitted for these operations. At the I / O layer, this information is encapsulated according to its type and format and passed to the Resmgr layer of the driver process's resource manager via kernel inter-process communication. The Resmgr layer is responsible for receiving the information and distributing it directly according to the defined information type, or distributing it through the Dispatch layer to the I / O function (Iofunc) layer for execution. Here, the I / O operation functions (io_xx) registered by the driver are called. The Dispatch layer mainly needs to distribute processing pulses and other custom types of operations; the process is similar and will not be detailed here. When the Resmgr layer calls the Iofunc layer, it directly exposes the context information of the information and the specific information type and format encapsulated by the I / O layer to the I / O functions registered by the driver. For example, taking the message `io_read(resmgr_context_t*ctp, io_read_t*msg, iofunc_ocb_t*ocb)` as an example, `resmgr_context_t` is the context information of the message, `io_read_t` is the read information structure defined by QNX, and `iofunc_ocb_t` is the open control block, pointing to the attribute structure of the opened device and the file offset, etc. An `ocb` is created each time a device is opened and destroyed when it is closed. In other words, each I / O interface function implemented by the driver needs to further parse these QNX-defined information structures and message contents before converting them into specific device operations.

[0029] Furthermore, although QNX provides default I / O operation functions for drivers, these functions are very basic, and most drivers still need to reimplement them. The Resource Manager's Resmgr layer only receives information and delegates most of the information parsing work to the drivers. While this provides some flexibility, each driver needs to implement a set of I / O operation functions (io_xx) adapted to the driver framework, which undoubtedly increases the complexity of driver development.

[0030] also, Figure 1The QNX driver framework exposes some internal information structures (io_xx), and by delegating pointers to these internal structures to the driver program, it introduces certain security vulnerabilities. For QNX driver developers, this first requires understanding the specific information types and formats defined by the QNX driver framework, as well as their usage, increasing development time costs. Simultaneously, implementing a set of I / O operation functions adapted to the QNX driver framework undoubtedly increases the complexity of driver development. For drivers ported from platforms such as Linux, significant modifications are required to adapt to the QNX driver framework, further increasing development difficulty.

[0031] To address the aforementioned technical issues, this application improves the hierarchical design of existing driver frameworks and optimizes the standardization of external interfaces. It can provide the driver process (server side) with a POSIX function interface equivalent to that of the user process (client side), hiding data transfer involved in inter-process communication and various information structures used in the driver framework within the driver framework itself. This achieves seamless interface connection between the user process and the driver process, and the driver framework can even centrally handle some performance optimization issues, thereby minimizing the complexity of driver development or porting and reducing the workload of driver development.

[0032] Figure 2 The present application provides a structural block diagram of an operating system 20, which includes a driver framework and further includes a kernel, an I / O layer, an operating system interface layer, a driver program, and a pathname manager.

[0033] Furthermore, the driver framework includes an inter-process communication interface layer and a driver core layer; the driver core layer includes a distribution module and a processing module, and the processing module includes an I / O function processing module and a pulse function processing module; wherein: the distribution module is used to receive request information from the client and distribute the request information to the processing module; the processing module is used to process the request information and call the operation function of the driver through the inter-process communication interface layer to access the device corresponding to the driver.

[0034] The driver framework's core layer and drivers reside within the driver process; the client is the application layer, residing in the user process. The driver framework's IPC interface layer (inter-process communication interface layer) is partially located in the driver process and partially in the user process, as detailed below. Figure 2 .

[0035] Specifically, the IPC interface layer is divided into two parts. One part is located in the I / O layer and is the serialization part of the user process, which interfaces with the user's I / O interface. The other part is the deserialization part of the IPC interface layer, which interfaces with the I / O functions registered by the driver after the message processing module of the driver core layer has finished processing. The user process and the driver process achieve direct communication after processing through the IPC interface layer.

[0036] In addition, the operating system interface layer is used to receive function call information sent by the client; the I / O layer calls the IPC interface layer to encapsulate the function call information into a request message in the kernel's inter-process communication information format, and sends the request message to the driver core layer of the driver framework through the kernel's inter-process communication; the driver core layer is used to call the driver's operation function based on the request message; the driver is used to access the device corresponding to the driver based on the operation function; the driver core layer is also used to register relevant information of the driver with the pathname manager, including the path name and inter-process communication channel number.

[0037] In this embodiment, the kernel can be an AliOS RTOS microkernel, where AliOS is an operating system, and RTOS stands for Real-time operating system. The kernel retains functions such as inter-process communication, process scheduling, interrupt handling, and MMU (Memory Management Unit).

[0038] The Register module in the driver calls the registration interface of the driver core layer. The driver core layer registers the path name (pathname) and inter-process communication channel number (IPC channel id, chid) with the pathname manager. This allows the client to first obtain the inter-process communication channel number (chid) from the pathname manager when calling the POSIX interface open (including pathname, flags, mode).

[0039] POSIX (Portable Operating System Interface for UNIX) is a standard interface used by operating systems. Once the driver process is implemented, user processes can access the driver process's devices, including hardware and virtual devices, through the standard POSIX interface to manipulate files. The operating system predefines the types and formats of information that user processes need to transmit when manipulating files via the standard POSIX interface. The I / O layer encapsulates this information according to these types and formats using serialization functions provided by the IPC interface layer of the driver framework, and then sends it to the driver process through inter-process communication mechanisms.

[0040] In the driver framework, the inter-process communication interface layer (IPC interface layer) abstracts a set of IPC interface layers that standardizes the external interfaces of the driver core layer. This allows direct interface with POSIX interfaces, suitable for both user processes and driver processes, enabling seamless interface calls between the two processes. The main function of the driver core layer is to receive information sent from the client, parse, process, and deserialize it, and then call the driver's operations functions to access the device. The driver core layer's dispatch module, after receiving information from the kernel's inter-process communication, performs preliminary parsing and dispatches the information. Ordinary I / O operations are dispatched to the I / O function processing module (IO Funcs), while pulse information is dispatched to the pulse function processing module (PulseFuncs) for further processing. Furthermore, the I / O Funcs ensures that user process information is completely reflected in the driver process space through copying or a Map (an object that maps keys to values). The driver can directly access these data spaces (unlike QNX, where the driver needs to read or write again via API based on the remaining bytes). Then, the IO Functions find the corresponding deserialization function `io_xx` at the IPC interface layer based on the information type. `io_xx` deserializes the received information body, parses it into the parameter format required by the operator registered by the driver, and then calls the operator registered by the driver to access the device. The parsing of information passed from the user process to the driver process is entirely handled by the driver framework. The driver does not need to worry about the information types and formats defined by the driver framework, or the conversion of information formats, nor does it need to worry about information integrity handling. It only needs to implement and register IO operation functions similar to the POSIX interface. In this way, the driver development process only needs to focus on the Register module and Operations, and does not need to develop a set of IO operation functions for different devices, thus reducing the development difficulty of the driver.

[0041] Furthermore, the driver framework of this application can also implement resource management operations of the corresponding QNX ocb (open control block), which is not limited here.

[0042] Figure 3 This is a flowchart illustrating the driver invocation method provided in this application embodiment. The execution entity in this embodiment can be... Figure 2 The driver framework in the illustrated embodiment. The method for invoking this driver specifically includes the following steps:

[0043] S301 uses a distribution module to receive request information sent by the client.

[0044] Among them, reference Figure 2 The request information is sent by the client to the I / O layer through the POSIX interface. After being encapsulated by the IPC interface layer, the I / O layer sends it to the distribution module of the driver core layer through the kernel's inter-process communication.

[0045] Furthermore, before the distribution module receives the request information sent by the client, the process includes: providing a registration interface to the driver during driver initialization so that the driver can call the registration interface to register; requesting an inter-process communication channel from the kernel using the driver core layer so that the kernel can establish a data transmission channel and allocate an inter-process communication channel number to the data transmission channel; registering the path name and inter-process communication channel number with the pathname manager using the driver core layer; and requesting resources and starting the service using the driver core layer.

[0046] In this embodiment of the application, the distribution module is used to receive request information sent by the client, including: when the client obtains the inter-process communication channel number from the path name manager based on the path name, the distribution module receives the request information sent by the client based on the inter-process communication channel number.

[0047] Specifically, the client first retrieves the channel number from the pathname manager using `open` based on the path name, and then sends a message to that channel number to the driver process. The corresponding wait handler function in the driver process will receive the message, thus completing message reception. All this transmission logic within `open` is encapsulated within the driver framework, so the client is unaware of it and only needs to call these standard POSIX interfaces.

[0048] S302, the distribution module distributes the request information to the processing module.

[0049] The distribution module sends the request information to the processing module (IO Funcs or Pulse Funcs) according to the type of request information.

[0050] S303 uses a processing module to process the information type and content of the request information, and after deserializing and adapting the driver's operation function through the inter-process communication interface layer, it calls the driver's operation function to access the device corresponding to the driver.

[0051] After parsing, the processing module obtains the corresponding io_xx functions, such as io_open, io_read, io_write, io_close, and io_unblock. These io_xx functions are then used to call the driver's operation functions to access the device corresponding to the driver.

[0052] In the embodiments of this application, Figure 2 In this context, `open` is the "start" operation, such as starting a device or opening a corresponding file. `read` is the "read" operation, such as using a device to read data from a database. `write` is the "write" operation, such as using a device to write data into memory. `close` is the "close" operation, such as stopping the use of a device. `ioctl` is the "call" operation. `unblock` is the "interrupt" operation.

[0053] The processing module includes an IO function processing module. This module processes the information type and content of the request information, and after deserialization and adaptation to the driver's operation functions through the inter-process communication interface layer, it calls the driver's operation functions. This includes: using the IO function processing module to call the deserialization function of the inter-process communication interface layer according to the information type and content of the request information; adapting the driver's operation functions based on the deserialization function; and then calling the driver's operation functions.

[0054] This application provides a driver framework, operating system, driver invocation method, and electronic device. The driver framework includes an inter-process communication interface layer and a driver core layer. The driver core layer includes a dispatch module and a processing module. The processing module includes an I / O function processing module and a pulse function processing module. The dispatch module receives request information from the client and dispatches it to the processing module. The processing module processes the request information and calls the driver's operation functions through the inter-process communication interface layer to access the device corresponding to the driver. By setting up a processing module within the driver framework, this application can parse the request information, ensure the integrity of data transmission in inter-kernel communication, and finally parse out the specific I / O function type. This avoids configuring a set of I / O functions adapted to the driver framework in the driver, reducing the development complexity of the driver.

[0055] Figure 4 This is a flowchart illustrating the driver invocation method provided in this application embodiment. The execution entity in this embodiment can be... Figure 2 The operating system in the illustrated embodiment. The method for invoking this driver specifically includes the following steps:

[0056] S401. After completing the registration of the operation functions, the driver starts the service of the driver process.

[0057] Reference Figure 2 This is a schematic diagram of the AliOS RTOS operating system, which also adopts a typical microkernel operating system client-server model.

[0058] The driver first implements the `do_xx` functions of `xx_operations`, which operate on the underlying device. Then, it registers with the driver kernel layer and requests relevant resources from the driver kernel layer through a series of initialization interfaces. The driver kernel layer registers the driver's pathname and chid information with the pathname manager. After registration, the driver process service starts and waits for clients to access it.

[0059] S402, the driver core layer receives request information sent by the client through the kernel's inter-process communication.

[0060] When S401 is complete, when the client calls the POSIX interface, it first obtains information such as the path name and chid from the path name manager. Then, the I / O layer calls the serialization function of the IPC interface layer to serialize and encapsulate the information type identifier of the request information into an information format that can be recognized by inter-process communication. Then, it is sent to the driver core layer through the inter-process communication mechanism.

[0061] S403. The driver core layer processes the request information and calls the driver's operation function through the inter-process communication interface layer to access the device corresponding to the driver.

[0062] The dispatch module in the driver core layer initially parses the type of request information. If it is a normal I / O operation, it will be handed over to the I / O Funcs layer for further processing. The I / O Funcs layer finds the deserialization function io_xx of the driver framework based on the information type identifier, parses the corresponding information content, and then finds the do_xx function pointer of xx_operations registered by the driver and attached to the driver core layer. It executes the driver's do_xx operation function, and the driver performs initialization operations. Some drivers will access the device and return results. The io_reply function in the driver core layer encapsulates the return results and other information into an inter-process communication information format and then returns it to the client through inter-process communication.

[0063] For example, refer to Figure 5 This completes the do_open and do_write processes for the operating system. It includes the following steps:

[0064] S1. Register resources, operations, etc. S2. Request a channel. S3. Return chid. S4. Register pathname / chid. S5. Request resources / start service. S6. Open request. S7. Return chid. S8. _open wrapper. S9. IPC transfer. S10. Receive data. S11. Look up io_open. S12. do_open. S13. Init operations, etc. S14. Return result. S15. Return result. S16. io_reply. S17. IPC transfer. S18. Return fd. S19. Write. S20. IPC transfer. S21. Receive data. S22. Process data. S23. Look up io_write. S24. do_write. S25. Write operation. S26. Return result. S27. Return result. S28. io_reply. S29. Return result. S30. Return len.

[0065] For S1 to S5, the driver first implements functions such as `do_open(pathname, flags, mode)` and `do_write(fd, buf, len)` of `xx_operations`. These functions operate on the underlying device and are then registered with the driver core layer. Simultaneously, the driver requests relevant resources from the driver core layer through a series of initialization interfaces, such as IPC channelid (chid). The driver core layer then registers the driver's pathname and chid information with the pathname manager. After registration, the driver process service starts and waits for clients to access it.

[0066] For S6 to S18, when a client calls the POSIX interface `open(pathname, flags, mode)`, it first retrieves information such as `chid` from the pathname manager. Then, the I / O layer's serialization function `_open` serializes and encapsulates the `pathname`, `flags`, `mode`, and the type identifier of the `open` function into an information format recognizable by inter-process communication (IPC). This information is then sent to the driver process with the IPC channel number `chid` via the IPC mechanism. Furthermore, since the IPC channel number is `chid`, when information arrives, the receiving thread is awakened by the kernel and receives the relevant data for the `open` operation from the kernel. The driver core's `dispatch` module initially parses this as a normal I / O operation and then hands it over to the I / O Functions layer for further processing. The IO Functions layer locates the deserialization function io_open of the driver framework based on the information type identifier, parses out information such as pathname, flags, and mode, and then finds the do_open function pointer of xx_operations registered and mounted to the driver core layer. It executes the driver's do_open(pathname, flags, mode) operation function, and the driver performs initialization operations. Some drivers will access the device and return the result. The driver core layer's io_reply function encapsulates the return result (such as file descriptor fd) and other information into an inter-process communication information format, and then returns it to the client through inter-process communication.

[0067] For S19 to S30, after the client obtains the file descriptor (fd), it can perform a `write(fd, buf, len)` operation. The driver framework's serialization function `_write` serializes and encapsulates the `fd`, `buf`, and `len` information of the write operation, along with the write information type identifier, into an inter-process communication (IPC) format, and then sends it to the driver process via IPC. The driver process handles the `write` message similarly to `open`, except that `write` needs to transmit a buffer of data. Unlike `open`, the data length is not fixed. Therefore, the IO Functions layer needs to ensure that the information to be written by the user process is completely reflected in the driver process. This requires data copying or mapping to completely copy or map the data to the driver process. After the IO Functions information is ready, the deserialization function `io_write` is executed, converting the prepared information into the required `buf` and `len` for writing. Then, the driver's `do_write(fd, buf, len)` operation function is called, which writes the data in `buf` to the device and returns the actual write length. The returned length and status information are encapsulated by `io_reply` and then returned to the user process's client via IPC.

[0068] In summary, the core driver layer of the driver framework in this application handles most of the information processing. Drivers only need to focus on the implementation of the specific `do_xx` functions within `xx_operations`. These functions are defined in accordance with POSIX definitions, making it as convenient as directly interfaced with a POSIX interface from the driver's perspective. This makes the driver framework easier to understand and facilitates driver development and portability. Driver developers do not need to concern themselves with the types and information formats of the operation functions defined by the driver framework. Performance optimizations for subsequent information transmission can also be centrally handled by the driver framework, eliminating the need for individual driver optimization efforts and reducing development difficulty and time costs.

[0069] Reference Figure 1 File Explorer and Figure 2 The driver core layer, assuming the driver needs to implement the do_xx IO interface function as an example, the driver framework of this application and the internal implementation of the resource manager are different. In particular, the driver framework of this application abstracts a set of IPC interface layers. The above has explained how the IPC interface layer is converted in the whole process. This IPC interface layer standardizes the external interface of the driver core layer and can directly interface with the POSIX interface. It is suitable for user processes and driver processes, so that the interface calls between the two processes are "seamlessly" connected.

[0070] Furthermore, this application provides an improvement to the layered design of the driver framework. Compared to the resource manager, the parsing and conversion of information formats required by the driver are integrated into the driver framework. Driver developers do not need to understand the information types and formats defined within the driver framework, nor do they need to expose pointers to the information structures within the driver framework to the driver, preventing accidental modification that could lead to erroneous logic or compromise the security of the driver process. Simultaneously, the driver framework can centrally optimize the performance of inter-process communication data transfer, reducing some of the optimization work in the driver and lowering the complexity and workload of driver development, thus facilitating driver development and portability.

[0071] Figure 6 A schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application, such as... Figure 6 As shown, the electronic device includes at least one processor 601 and a memory 602.

[0072] The processor 601 is used to store computer execution instructions.

[0073] The memory 602 is used to execute computer execution instructions stored in the memory to implement the various steps involved in the above method embodiments. For details, please refer to the relevant descriptions in the foregoing method embodiments.

[0074] Alternatively, the memory 602 can be either standalone or integrated with the processor 601.

[0075] When the memory 602 is set up independently, the controller also includes a bus 603 for connecting the memory 602 and the processor 601.

[0076] This invention also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described driver invocation method.

[0077] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described driver invocation method.

[0078] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules 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, indirect coupling or communication connection between devices or modules, and may be electrical, mechanical, or other forms.

[0079] The modules described above as separate components may or may not be physically separate. The components shown as modules 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 modules can be selected to implement the solution of this embodiment according to actual needs.

[0080] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0081] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, electronic device, or network device, etc.) or processor to execute partial steps of the methods of the various embodiments of this application.

[0082] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0083] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.

[0084] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0085] The aforementioned storage medium can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium accessible to general-purpose or special-purpose computers.

[0086] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. Both the processor and the storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components in an electronic device or host device.

[0087] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0088] This description is intended to illustrate the technical solutions of this application, and not to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method of calling a driver program, characterized by, The application is applied to a driving framework, the driving framework comprises a driving core layer, the driving core layer comprises a distribution module, a processing module and an inter-process communication interface layer, the processing module comprises an IO function processing module and a pulse function processing module; the calling method of the driving program comprises: receiving request information sent by a client by using the distribution module; distributing the request information to the processing module by using the distribution module; processing information type and information content of the request information by using the processing module, finding a corresponding deserialization function of the inter-process communication interface layer according to the information type, parsing the request information into a parameter format required by an operation function of the driving program, calling the operation function of the driving program to access a device corresponding to the driving program.

2. The method of claim 1, wherein the driver is called by a driver call module. The processing module comprises the IO function processing module, and processing information type and information content of the request information by using the processing module, finding a corresponding deserialization function of the inter-process communication interface layer according to the information type, parsing the request information into a parameter format required by an operation function of the driving program, calling the operation function of the driving program, comprises: calling the deserialization function of the inter-process communication interface layer according to the information type and information content of the request information by using the IO function processing module; adapting the operation function of the driving program based on the deserialization function, and then calling the operation function of the driving program.

3. The method of claim 1, wherein the driver is called by a driver call module. Before the receiving request information sent by a client by using the distribution module, the method further comprises: in the case of initializing the driving program, providing a registration interface to the driving program by using the driving core layer, so that the driving program calls the registration interface to register; applying for an inter-process communication channel to the kernel by using the driving core layer, so that the kernel establishes a data transmission channel and allocates an inter-process communication channel number to the data transmission channel; registering a path name and the inter-process communication channel number to the path name manager by using the driving core layer, so that the client obtains the inter-process communication channel number from the path name manager according to the path name; the driving program applies for resources to the driving core layer and starts a service of a driving process.

4. The method of claim 3, wherein the driver is called by the operating system. The receiving request information sent by a client by using the distribution module comprises: in the case that the client obtains the inter-process communication channel number from the path name manager according to the path name, receiving request information sent by the client according to the inter-process communication channel number by using the distribution module.

5. A method of calling a driver program, characterized by, The application is applied to an operating system, the operating system comprises a driving framework, the driving framework comprises a driving core layer, the driving core layer comprises a distribution module, a processing module and an inter-process communication interface layer, the processing module comprises an IO function processing module and a pulse function processing module; the operating system further comprises a kernel, an I / O layer, an operating system interface layer, a driving program and a path name manager, wherein, the operating system interface layer is used for receiving function calling information sent by a client; The I / O layer encapsulates the function call information into a request information in an inter-process communication information format of the kernel based on an inter-process communication interface layer arranged in the I / O layer, and sends the request information to a driver core layer of the driver framework through inter-process communication of the kernel; The driver framework is configured to process an information type and information content of the request information, find a corresponding deserialization function of an inter-process communication interface layer arranged in the driver core layer according to the information type, parse the request information into a parameter format required by an operation function of the driver program, and call the operation function of the driver program; The driver program is configured to access a device corresponding to the driver program based on the operation function; The driver framework is further configured to register related information of the driver program to a path name manager, the related information including a path name and an inter-process communication channel number; The calling method of the driver program includes: After the registration of the operation function is completed, the driver program starts a service of a driver process; The driver core layer receives the request information sent by the client through inter-process communication of the kernel; The driver core layer processes the request information and calls an operation function of a driver program through the inter-process communication interface layer to access a device corresponding to the driver program.

6. An electronic device, comprising: Comprise: At least one processor and a memory; The memory stores computer execution instructions; The at least one processor executes the computer execution instructions stored in the memory, so that the at least one processor executes the calling method of the driver program according to any one of claims 1 to 5.

7. A computer readable storage medium characterized by The computer readable storage medium stores at least one computer execution instruction, and when the processor executes the computer execution instruction, the calling method of the driver program according to any one of claims 1 to 5 is realized.

8. A computer program product, characterised in that, The computer program is executed by the processor to realize the calling method of the driver program according to any one of claims 1 to 5.

Images