Microkernel architecture device driving method, apparatus, electronic device, and storage medium

Abstract

Embodiments of the present disclosure relate to a device driver method and device based on a microkernel architecture, an electronic device and a storage medium. In at least one embodiment of the present disclosure, a master-slave thread architecture mode of a driver master thread and a device slave thread is adopted, at the time of starting an operating system, only the driver master thread is started, and the device slave thread is not started, so as to reduce the consumption of system resources by the device slave thread; and the driver master thread and the device slave thread provide device driver services through an RPC mode, specifically, after the driver master thread receives a first RPC message which is a device start request, the driver master thread starts the device slave thread of the device node, and then after the device slave thread determines that a second RPC message received is a device operation request, the device node is operated correspondingly, so as to solve the problem that in the current microkernel architecture, an application cannot directly call a device driver.

Description

TECHNICAL FIELD

[0001] Embodiments of the present disclosure relate to the technical field of computer, in particular, to a device driver method and apparatus of micro-kernel architecture, electronic device and non-transitory computer-readable storage medium. BACKGROUND

[0002] An operating system (OS) is a computer program that manages computer hardware and software resources. A system call is the smallest unit of function of an operating system. The operating system is divided into a kernel mode (which can be understood as a kernel space) and a user mode (which can be understood as a user space) by the system call. The kernel is a special software program of the operating system, which runs directly on the hardware and can be understood as a bridge connecting the application program and the hardware. The kernel is used to control the hardware resources of the computer, such as coordinating the central processing unit (CPU) resources, allocating memory resources and providing a stable environment for the application program to run. The user mode can be understood as a space for the application program to run. In order to enable the application program to access the resources managed by the kernel, such as CPU resources, memory resources and I / O (Input / Output) resources, the kernel needs to provide a set of common access interfaces, which are system calls.

[0003] Currently, there are two kinds of kernel architectures of operating systems: macro-kernel architecture and micro-kernel architecture. Figure 1 The architecture schematic diagram of the macro-kernel and the architecture schematic diagram of the micro-kernel are shown by Figure 1 It can be seen that in the macro-kernel architecture, the components, applications and device drivers run in the kernel mode, so the components and applications can directly call the device drivers. In the micro-kernel architecture, the device drivers run in the user mode, for example, in process 1, and the components and applications run in the user mode, for example, in process 2. In this way, the components and applications cannot directly call the device drivers. Therefore, it is urgent to provide a device driver scheme of micro-kernel architecture. SUMMARY

[0004] In order to solve at least one problem existing in the prior art, at least one embodiment of the present disclosure provides a device driver method and apparatus of micro-kernel architecture, electronic device and non-transitory computer-readable storage medium.

[0005] In a first aspect, an embodiment of the present disclosure provides a device driver method of micro-kernel architecture, wherein an operating system starts a driver main thread in response to a start instruction, and does not start a device sub-thread. The device driver method comprises:

[0006] The driver main thread receives a first RPC message through an RPC service;

[0007] The driving main thread determines that the first RPC message is a device start request, and starts a device sub-thread of a corresponding device node;

[0008] The device sub-thread receives a second RPC message through the RPC service after being started;

[0009] The device sub-thread determines that the second RPC message is a device operation request, and performs a corresponding device operation on the device node.

[0010] In some embodiments, before the driving main thread receives the first RPC message through the RPC service, the device driving method further comprises:

[0011] The driving main thread registers and starts a main thread RPC service;

[0012] The driving main thread registers an RPC service of one or more device nodes and registers each device node after starting the main thread RPC service.

[0013] In some embodiments, after the driving main thread determines that the first RPC message is a device start request, the device sub-thread of the corresponding device node is started, comprising:

[0014] The driving main thread determines that the first RPC message is a device start request, and opens a device node corresponding to the device start request;

[0015] The driving main thread starts a device sub-thread of the device node after opening the device node.

[0016] In some embodiments, after the driving main thread determines that the first RPC message is a device start request, the device sub-thread of the corresponding device node is started, comprising:

[0017] The driving main thread determines that the first RPC message is a device start request, and calls a thread creation API provided by an operating system to create a device sub-thread of a device node corresponding to the device start request.

[0018] In some embodiments, the device driving method further comprises:

[0019] The device sub-thread opens the corresponding device node after being started;

[0020] The device sub-thread performs a corresponding device operation on the device node after opening the device node and determining that the second RPC message is a device operation request.

[0021] In some embodiments, the RPC service of one or more device nodes is registered and each device node is registered, comprising:

[0022] The driving main thread scans a driving list to obtain one or more device types and device nodes corresponding to each device type;

[0023] The driving main thread registers an RPC service of each device node;

[0024] The driving main thread registers each device node after registering the RPC service of each device node.

[0025] In some embodiments, the registering each device node comprises:

[0026] Registering each device node to a first VFS library, wherein the first VFS library is a VFS library of a process where the driving main thread is located; or, registering each device node to a PM process.

[0027] In some embodiments, the device start request is sent by an application process in the following way:

[0028] The application process looks up whether the device node to be started has been registered in a second VFS library, wherein the second VFS library is a VFS library of the application process; if not, the application process looks up the main thread RPC service;

[0029] The application process sends the device start request to the driving main thread based on the main thread RPC service.

[0030] In some embodiments, the application process looks up the RPC service of the device node to be started while looking up the main thread RPC service;

[0031] After the application process receives the device start result fed back by the driving main thread, if the device start result is successful, the application process sends a device operation request to a device sub-thread based on the RPC service of the device node to be started.

[0032] In some embodiments, the driving main thread registers and starts the main thread RPC service in the PM process; and the application process looks up the main thread RPC service in the PM process.

[0033] In some embodiments, the device driving method further comprises:

[0034] After the driving main thread determines that the first RPC message is the device close request, the driving main thread ends the device sub-thread of the corresponding device node.

[0035] After the driving main thread ends the device sub-thread of the corresponding device node, the driving main thread closes the device node.

[0036] In a second aspect, the embodiments of the present disclosure further provide a device driving apparatus based on a microkernel architecture, wherein the device driving apparatus comprises a driving main thread and a device sub-thread; an operating system starts the driving main thread in response to a start instruction, and does not start the device sub-thread.

[0037] The driving main thread is used to receive a first RPC message through an RPC service, and determine that the first RPC message is a device start request, and then start a device sub-thread of a corresponding device node;

[0038] The device sub-thread is used to receive a second RPC message through the RPC service after being started, and determine that the second RPC message is a device operation request, and then perform a corresponding device operation on the device node.

[0039] In a third aspect, the embodiments of the present disclosure further provide an electronic device, comprising a processor and a memory; the processor is used to execute the steps of the device driving method of the microkernel architecture according to the first aspect by calling programs or instructions stored in the memory.

[0040] In a fourth aspect, the embodiments of the present disclosure further provide a non-transitory computer readable storage medium, used to store programs or instructions, which make a computer execute the steps of the device driving method of the microkernel architecture according to the first aspect.

[0041] It can be seen that, in at least one embodiment of the present disclosure, the master-slave thread architecture mode of the driving main thread and the device sub-thread is adopted, and only the driving main thread is started without starting the device sub-thread when the operating system is started, so as to reduce the consumption of system resources by the device sub-thread; and the driving main thread and the device sub-thread provide device driving services through the RPC mode, specifically, when the first RPC message received by the driving main thread is a device start request, the driving main thread starts the device sub-thread of the device node, and then the device sub-thread determines that the second RPC message received is a device operation request, and performs a corresponding operation on the device node, so as to solve the problem that the application cannot directly call the device driver in the current microkernel architecture. BRIEF DESCRIPTION OF DRAWINGS

[0042] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only some embodiments of the present disclosure, and other drawings can also be obtained by those skilled in the art according to these drawings.

[0043] Figure 1 is a schematic diagram of the macrokernel architecture and the microkernel architecture;

[0044] Figure 2 is a flowchart of a device driving method of a microkernel architecture provided by the embodiments of the present disclosure;

[0045] Figure 3 is a flowchart of starting a device sub-thread provided by the embodiments of the present disclosure;

[0046] Figure 4is a flowchart of another process for starting a device sub-thread provided by an embodiment of the present disclosure;

[0047] Figure 5 is an interaction diagram of a device driving method of a micro-kernel architecture provided by an embodiment of the present disclosure;

[0048] Figure 6 is an exemplary block diagram of a device driving apparatus of a micro-kernel architecture provided by an embodiment of the present disclosure;

[0049] Figure 7 is an exemplary block diagram of an electronic device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0050] In order to more clearly understand the above-mentioned purposes, features and advantages of the present disclosure, the present disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. It can be understood that the described embodiments are part of the embodiments of the present disclosure, rather than all the embodiments. The specific embodiments described herein are merely used to explain the present disclosure, but not to limit the present disclosure. All other embodiments obtained by those of ordinary skill in the art based on the described embodiments of the present disclosure are within the scope of protection of the present disclosure.

[0051] It should be noted that, in this document, relational terms such as "first" and "second", and the like, are used solely to distinguish one entity or action from another entity or action, without necessarily requiring or implying any actual such relationship or order between such entities or actions.

[0052] The micro-kernel is an operating system kernel that can provide necessary services, including but not limited to tasks, threads, inter-process communication (IPC) and memory management, etc. All services (including device drivers) run in user mode, and processing these services is the same as processing any other program, because each service only runs in its own address space.

[0053] To solve at least one problem existing in the prior art, at least one embodiment of the present disclosure provides a device driver method, device, electronic device and non-transitory computer readable storage medium of microkernel architecture, which adopts a master-slave thread architecture mode to design the device driver loading mode and the application programming interface (API) of the service provided by the device driver. The device driver loading includes RPC service registration of the device node and registration of the device node. The service provided by the device driver includes device start request (open), device close request (close) and device operation request, wherein the device operation request includes but is not limited to write request (write), read request (read), input / output request (ioctl) and the like.

[0054] In at least one embodiment of the present disclosure, a master-slave thread architecture mode of a driving master thread and a device slave thread is adopted, at the start of the operating system, only the driving master thread is started, and the device slave thread is not started, so as to reduce the consumption of system resources by the device slave thread; and the driving master thread and the device slave thread provide device driver services through an RPC mode, specifically, when the first RPC message received by the driving master thread is a device start request, the driving master thread starts the device slave thread of the device node, and then when the second RPC message received by the device slave thread is determined to be a device operation request, the device node is operated correspondingly, so as to solve the problem that in the microkernel architecture, the application cannot directly call the device driver.

[0055] Figure 2 is a flowchart of a device driver method of microkernel architecture provided by an embodiment of the present disclosure. When the operating system adopting the microkernel architecture is started, for example, the operating system receives a start instruction, the start instruction is for example an instruction generated by the user pressing the power-on key, the operating system responds to the start instruction and only starts the driving master thread, and does not start the device slave thread, so as to reduce the consumption of software and hardware resources of the operating system by the device slave thread. In some embodiments, there can be multiple device slave threads, each device slave thread corresponds to a device node, and no matter how many device slave threads there are, the operating system does not start these device slave threads when starting.

[0056] After the driving master thread is started by the operating system, in step 201, the driving master thread receives a first RPC message through an RPC service.

[0057] The RPC (Remote Procedure Call) service is a way for different processes to interact in the micro-service architecture. Although the application in the micro-service architecture cannot directly call the device driver, the application process can send a first RPC message to the process where the device driver is located through the RPC method. In this way, the driver main thread can provide device driver services through the RPC method.

[0058] In step 202, the driver main thread determines that the first RPC message is a device startup request, and starts the device sub-thread of the corresponding device node.

[0059] The device driver service provided by the driver main thread through the RPC method includes a device startup request (open). In this way, the application process can send a device startup request to the driver main thread through the RPC method, and the device startup request carries the information of the device node to be started.

[0060] After the driver main thread determines that the received first RPC message is a device startup request, it can determine the device node corresponding to the device startup request based on the information of the device node carried in the device startup request, and then start the device sub-thread of the corresponding device node.

[0061] As can be seen, the start of the device sub-thread is controlled by the driver main thread. When an application process needs to use a certain device node, the driver main thread will start the device sub-thread of the device node. In this way, the consumption of operating system software and hardware resources by the device sub-thread when the device node is not used can be reduced.

[0062] In step 203, the device sub-thread receives a second RPC message through the RPC service after being started.

[0063] After being started, the device sub-thread can provide device driver services through the RPC method. The device driver service is, for example, a device operation request, which includes but is not limited to a write request (write), a read request (read), an input / output request (ioctl), etc. In this way, the application process can send a device operation request to the device sub-thread through the RPC method.

[0064] It should be noted that the second RPC message received by the device sub-thread after being started is for the device node corresponding to the device sub-thread.

[0065] In step 204, the device sub-thread determines that the second RPC message is a device operation request, and performs a corresponding device operation on the device node.

[0066] If the device operation request is a write request, the device sub-thread performs a write operation on the device node; if the device operation request is a read request, the device sub-thread performs a write operation on the device node; if the device operation request is an input / output request, the device sub-thread performs an input / output operation on the device node.

[0067] It can be seen that in the embodiment, the master-slave thread architecture mode of the driving master thread and the device sub-thread is adopted, at the start of the operating system, only the driving master thread is started, and the device sub-thread is not started, thereby reducing the consumption of system resources by the device sub-thread; and the driving master thread and the device sub-thread provide device driving services through the RPC mode, specifically, when the first RPC message received by the driving master thread is a device start request, the driving master thread starts the device sub-thread of the device node, and then the device sub-thread determines that the second RPC message received is a device operation request, and performs corresponding operations on the device node, thereby solving the problem that in the current microkernel architecture, the application cannot directly call the device driver.

[0068] In some embodiments, before the driving master thread receives the first RPC message through the RPC service, the driving master thread needs to register and start the master thread RPC service, and then the first RPC message can be received through the master thread RPC service.

[0069] After the driving master thread registers and starts the master thread RPC service, the driving master thread can register the RPC service of one or more device nodes and register each device node. In some embodiments, the driving master thread can scan the driver list to obtain one or more device types and the device nodes corresponding to each device type, and then register the RPC service of each device node and register each device node. In this way, any device sub-thread can receive the second RPC message through the RPC service of the device node corresponding to the device sub-thread after the device sub-thread is started.

[0070] In some embodiments, after the driving master thread determines that the first RPC message is a device start request, there are various ways to start the device sub-thread of the corresponding device node.

[0071] For example, Figure 3 A flowchart for starting a device sub-thread is provided in the embodiment of the present disclosure. In step 301, the driving master thread receives a device start request. In this step, the driving master thread waits to receive a first RPC message, and when the driving master thread determines that the received first RPC message is a device start request, step 302 is performed.

[0072] In step 302, the driving main thread opens the device node corresponding to the device start request. In this step, the driving main thread can determine the corresponding device node based on the information (for example, the name of the device node) of the device node carried in the device start request, and then open the device node. In some embodiments, the driving main thread opens the device node by pointing the ops (operation method) pointer to the member: open of the ops structure, that is, ops->open.

[0073] In step 302, the driving main thread starts the device sub-thread of the device node after opening the device node. Since the device sub-thread is started after the device node is opened, the device sub-thread can directly receive the second RPC message through the RPC service after being started.

[0074] For another example, Figure 4 Another flowchart for starting a device sub-thread is provided in the embodiments of the present disclosure. Step 401 is the same as step 301 in Figure 3 , and will not be repeated here.

[0075] In step 402, the driving main thread calls the thread creation API provided by the operating system to create the device sub-thread of the device node corresponding to the device start request. In this embodiment, unlike the Figure 3 embodiment, after receiving the device start request, the driving main thread does not first open the device node and then start the device sub-thread of the device node, but directly calls the thread creation API to create the device sub-thread of the device node.

[0076] In step 403, the device sub-thread opens the corresponding device node after being started. Unlike the Figure 3 embodiment, the device node is not opened by the driving main thread, but by the device sub-thread. Specifically, the device sub-thread points the ops (operation method) pointer to the member: open of the ops structure, that is, ops->open, to open the device node.

[0077] After opening the device node, the device sub-thread determines that the second RPC message is a device operation request, and performs the corresponding device operation on the device node.

[0078] In some embodiments, when registering each device node, the driving main thread can register each device node to the first VFS (Virtual File System, virtual file system) library, where the first VFS library is the VFS library of the process in which the driving main thread is located; or the driving main thread can register each device node to the PM (Pass Manager, path management) process.

[0079] In some embodiments, the application process looks up in a second VFS library whether the device node to be started has been registered, wherein the second VFS library is the VFS library of the application process; if not, the application process looks up the main thread RPC service. In some embodiments, the main thread RPC service is registered and started in the PM process by the driver main thread, and thus the application process looks up the main thread RPC service in the PM process, and the PM process feeds back the query result to the application process.

[0080] After the application process finds the main thread RPC service, the application process can send a device starting request to the driver main thread based on the main thread RPC service.

[0081] In some embodiments, the application process looks up the main thread RPC service while also looking up the RPC service of the device node to be started. In some embodiments, the main thread RPC service is registered and started in the PM process by the driver main thread, and the RPC service of the device node is also registered in the PM process by the driver main thread, and thus the application process looks up the main thread RPC service and the RPC service of the device node to be started in the PM process, and the PM process feeds back the query result to the application process.

[0082] After the application process receives the device starting result fed back by the driver main thread, if the device starting result is successful, the application process sends a device operation request to the device sub-thread based on the RPC service of the device node to be started.

[0083] In some embodiments, the device driving service provided by the driver main thread through the RPC mode includes a device closing request (open), and thus the application process can send a device closing request to the driver main thread through the RPC mode, and carries the information of the device node to be closed or the device starting result in the device starting request, so that the driver main thread can determine the device node corresponding to the device closing request.

[0084] After the driver main thread determines that the first RPC message is the device closing request, the driver main thread ends the device sub-thread of the corresponding device node. After the driver main thread ends the device sub-thread of the corresponding device node, the driver main thread closes the device node. In some embodiments, the driver main thread closes the device node by pointing the ops (operation method) pointer to the member: close of the ops structure, that is, ops->close.

[0085] In combination with the description of the above method embodiments, Figure 5 is an interaction diagram of a device driving method of a microkernel architecture provided by the embodiments of the present disclosure. It should be noted that Figure 5 are only some embodiments of the present disclosure, not all embodiments.

[0086] In Figure 5In the embodiment, only one device sub-thread is shown for the convenience of description, and those skilled in the art can understand that there can be multiple device sub-threads, and the interaction process is similar.

[0087] In the embodiment, the operating system adopting the microkernel architecture starts the driver main thread without starting the device sub-thread when starting, for example, the operating system receives a starting instruction, for example, an instruction generated by the user pressing the power-on button, and the operating system starts the driver main thread in response to the starting instruction, thereby reducing the consumption of the operating system software and hardware resources by the device sub-thread. Figure 5 In the embodiment, the driver main thread registers and starts the main thread RPC service in the PM process after starting, and registers the RPC service of the device node and the device node in the PM process. After the above registration is completed, the driver main thread can wait for the RPC message.

[0088] Figure 5 In the embodiment, the application process queries the RPC service in the PM process to query whether the device node to be started has been registered in the second VFS library, wherein the second VFS library is the VFS library of the application process.

[0089] In the embodiment, the PM process feeds back the query result to the application process, wherein the query result includes the main thread RPC service information and the service information of the device node to be started. After obtaining the query result, the application process sends a device starting request to the driver main thread based on the main thread RPC service, and the device starting request carries the information of the device node (for example, the name of the device node). Figure 5 In the embodiment, the driver main thread receives the device starting request, determines the corresponding device node based on the information of the device node carried in the device starting request, and then opens the device node by pointing the ops (operation method) pointer to the member: open of the ops structure, that is, ops->open.

[0090] In the embodiment, the driver main thread starts the device sub-thread of the device node after opening the device node, and feeds back the device starting result to the application process. Since the device sub-thread is started after the device node is opened, the device sub-thread can directly wait for the RPC message after being started.

[0091] Figure 5 In the embodiment, the application process receives the device starting result fed back by the driver main thread, and if the device starting result is successful, the application process sends a device operation request to the device sub-thread based on the RPC service of the device node to be started.

[0092] In the embodiment, the application process receives the device starting result fed back by the driver main thread, and if the device starting result is successful, the application process sends a device operation request to the device sub-thread based on the RPC service of the device node to be started.

[0093] In the embodiment, the application process receives the device starting result fed back by the driver main thread, and if the device starting result is successful, the application process sends a device operation request to the device sub-thread based on the RPC service of the device node to be started. Figure 5 In the embodiment, the application process receives the device starting result fed back by the driver main thread, and if the device starting result is successful, the application process sends a device operation request to the device sub-thread based on the RPC service of the device node to be started.​​

[0094] The device sub-thread receives the device operation request, and performs a corresponding device operation on the device node. If the device operation request is a write request, the device sub-thread performs a write operation on the device node; if the device operation request is a read request, the device sub-thread performs a write operation on the device node; and if the device operation request is an input / output request, the device sub-thread performs an input / output operation on the device node.

[0095] In Figure 5 In this way, the application process can send a device closing request to the driver main thread, and carry information of a device node to be closed or a device starting result in the device starting request, so that the driver main thread can determine the device node corresponding to the device closing request.

[0096] After receiving the device closing request, the driver main thread ends the device sub-thread of the corresponding device node. After ending the device sub-thread of the corresponding device node, the driver main thread points the ops (operation method) pointer to the member: close of the ops structure, that is, ops->close, to close the device node.

[0097] As can be seen, Figure 6 The interaction flow of the device driving method of the microkernel architecture shown in the figure adopts the master-slave thread architecture mode of the driver main thread and the device sub-thread. When the operating system is started, only the driver main thread is started, and the device sub-thread is not started, thereby reducing the consumption of system resources by the device sub-thread. In addition, the driver main thread and the device sub-thread provide device driving services through the RPC mode. Specifically, after the driver main thread receives a device starting request, the driver main thread starts the device sub-thread of the device node, and then the device sub-thread performs a corresponding operation on the device node based on the received device operation request, thereby solving the problem that the application cannot directly call the device driver in the current microkernel architecture.

[0098] Figure 7 The device driving apparatus provided by the embodiment of the present disclosure comprises a driver main thread 61 and a device sub-thread 62. The operating system adopting the microkernel architecture starts the driver main thread 61 in response to a starting instruction, and does not start the device sub-thread 62. The device driving apparatus can comprise a plurality of device sub-threads 62, and each device sub-thread 62 corresponds to a device node.

[0099] The driver main thread 61 is configured to receive a first RPC message through an RPC service, and determine that the first RPC message is a device starting request, and start a device sub-thread 62 of a corresponding device node.

[0100] The device sub-thread 62 is configured to, after being started, receive the second RPC message through the RPC service, and after determining that the second RPC message is a device operation request, perform a corresponding device operation on the device node.

[0101] In some embodiments, the driving main thread 61 is further configured to, before receiving the first RPC message through the RPC service, register and start the main thread RPC service, and after starting the main thread RPC service, register the RPC service of one or more device nodes and register each device node.

[0102] In some embodiments, after the driving main thread 61 determines that the first RPC message is a device start request, the driving main thread 61 starts the device sub-thread 62 of the corresponding device node, specifically including: after determining that the first RPC message is a device start request, opening the device node corresponding to the device start request; after opening the device node, starting the device sub-thread 62 of the device node.

[0103] In some embodiments, after the driving main thread 61 determines that the first RPC message is a device start request, the driving main thread 61 starts the device sub-thread 62 of the corresponding device node, specifically including: after determining that the first RPC message is a device start request, calling a thread creation API provided by an operating system to create the device sub-thread 62 of the device node corresponding to the device start request.

[0104] In some embodiments, after the device sub-thread 62 is started, the device sub-thread 62 opens the corresponding device node, and after opening the device node, and after determining that the second RPC message is a device operation request, the device sub-thread 62 performs a corresponding device operation on the device node.

[0105] In some embodiments, the driving main thread 61 registers the RPC service of one or more device nodes and registers each device node, specifically including: scanning a driver list to obtain one or more device types and the device node corresponding to each device type; registering the RPC service of each device node; and after registering the RPC service of each device node, registering each device node.

[0106] In some embodiments, the driving main thread 61 registers each device node, specifically including: registering each device node to a first VFS library, wherein the first VFS library is a VFS library of a process in which the driving main thread is located; or, registering each device node to a PM process.

[0107] In some embodiments, the device start request is sent by an application process through the following manner:

[0108] The application process looks up in the second VFS library whether the device node to be started has been registered, wherein the second VFS library is the VFS library of the application process; if not, the application process looks up the main thread RPC service; and the application process sends a device starting request to the driver main thread based on the main thread RPC service.

[0109] In some embodiments, the application process looks up the RPC service of the device node to be started while looking up the main thread RPC service. After the application process receives the device starting result fed back by the driver main thread, if the device starting result is successful, the application process sends a device operation request to the device sub-thread based on the RPC service of the device node to be started.

[0110] In some embodiments, the driver main thread 61 registers and starts the main thread RPC service in the PM process. The application process looks up the main thread RPC service in the PM process.

[0111] In some embodiments, after the driver main thread 61 determines that the first RPC message is a device closing request, the driver main thread 61 ends the device sub-thread 62 of the corresponding device node; and after the driver main thread 61 ends the device sub-thread 62 of the corresponding device node, the driver main thread 61 closes the device node.

[0112] The details of the above device embodiments can refer to the details of the method examples, and will not be repeated here.

[0113] Figure 7 is a structural schematic diagram of an electronic device provided by an embodiment of the present disclosure. As shown in Figure 7 , the electronic device includes at least one processor 71, at least one memory 72, and at least one communication interface 73. The various components in the electronic device are coupled together through a bus system 74. The communication interface 73 is used for information transmission between the external device. Understandably, the bus system 74 is used to realize the connection communication between these components. In addition to including a data bus, the bus system 74 also includes a power bus, a control bus, and a status signal bus. However, for the purpose of clear illustration, all kinds of buses are marked as the bus system 74 in ​ .

[0114] It can be understood that the memory 72 in the embodiment can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories.

[0115] In some embodiments, the memory 72 stores the following elements, executable units or data structures, or a subset of them, or an expanded set of them: an operating system and an application program.

[0116] The operating system includes various system programs, such as a framework layer, a core library layer, a driver layer, and the like, for implementing various basic tasks and processing hardware-based tasks. The application programs include various application programs, such as a media player (Media Player), a browser (Browser), and the like, for implementing various application tasks. The program implementing the device driver method of the microkernel architecture provided in the embodiments of the present disclosure can be included in the application program or the operating system.

[0117] In the embodiments of the present disclosure, the processor 71 processes the program or instruction stored in the memory 72, specifically, the program or instruction stored in the application program, and the processor 71 is configured to perform the steps of each embodiment of the device driver method of the microkernel architecture provided in the embodiments of the present disclosure.

[0118] The device driver method of the microkernel architecture provided in the embodiments of the present disclosure can be applied to the processor 71 or implemented by the processor 71. The processor 71 can be an integrated circuit chip with a signal processing capability. In the implementation process, each step of the above method can be completed by an integrated logic circuit or an instruction in the form of software in the processor 71. The processor 71 described above can be a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0119] The steps of the device driver method of the microkernel architecture provided in the embodiments of the present disclosure can be directly embodied as a hardware decoding processor for execution, or a combination of hardware and software in the decoding processor for execution. The software unit can be located in a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, a register, and the like mature storage medium in the art. The storage medium is located in the memory 72, and the processor 71 reads the information in the memory 72, and combines the hardware to complete the steps of the method.

[0120] It should be noted that, for each of the above method embodiments, in order to simply describe, it is expressed as a combination of a series of actions, but those skilled in the art can understand that the embodiments of the present disclosure are not limited by the described action sequence, because according to the embodiments of the present disclosure, certain steps can be performed in other order or simultaneously. In addition, those skilled in the art can understand that the embodiments described in the specification all belong to optional embodiments.

[0121] The embodiments of the present disclosure further provide a non-transitory computer readable storage medium storing programs or instructions, which cause a computer to perform the steps of the method for device driving in the microkernel architecture. For the sake of brevity, the description will not be repeated here.

[0122] It should be noted that, in this document, the terms "comprising", "including", or any other variant thereof are intended to cover a non-exclusive inclusion, such that processes, methods, articles, or apparatuses that comprise a list of elements not only include those elements, but also include other elements not expressly listed, or also include elements inherent in such processes, methods, articles, or apparatuses. Without more limitations, an element defined by the statement "comprising" does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0123] Those skilled in the art can understand that, although some embodiments described herein include certain features and not others included in other embodiments, the combination of features of different embodiments means to be within the scope of the present disclosure and form different embodiments.

[0124] Those skilled in the art can understand that the description of each embodiment is focused on, and the parts not described in detail in a certain embodiment can refer to the relevant description of other embodiments.

[0125] Although the embodiments of the present disclosure are described in conjunction with the drawings, various modifications and changes can be made by those skilled in the art without departing from the spirit and scope of the present disclosure, and such modifications and changes fall within the scope defined by the appended claims.

Claims

1. A device driver method of a microkernel architecture, wherein, The method comprises the following steps: The driver main thread receives a first RPC message through an RPC service; The driver main thread starts a device sub-thread of a corresponding device node after determining that the first RPC message is a device start request; The device sub-thread receives a second RPC message through the RPC service after being started; The device sub-thread performs a corresponding device operation on the device node after determining that the second RPC message is a device operation request.

2. The method of claim 1, wherein, Before the driver main thread receives the first RPC message through the RPC service, the method further comprises the following steps: The driver main thread registers and starts a main thread RPC service; The driver main thread registers an RPC service of one or more device nodes and registers each device node after starting the main thread RPC service.

3. The method of claim 1, wherein, The driver main thread opens a device node corresponding to the device start request after determining that the first RPC message is a device start request; The driver main thread starts a device sub-thread of the device node after opening the device node. The driver main thread calls a thread creation API provided by the operating system to create a device sub-thread of a device node corresponding to the device start request after determining that the first RPC message is a device start request.

4. The method of claim 1, wherein, The method further comprises the following steps: The device sub-thread opens a corresponding device node after being started; 5. The method of claim 4, wherein, The device sub-thread performs a corresponding device operation on the device node after opening the device node and determining that the second RPC message is a device operation request. The driver main thread scans a driver list to obtain one or more device types and a device node corresponding to each device type; The driver main thread registers an RPC service of each device node; 6. The method of claim 2, wherein, The driver main thread registers each device node after registering an RPC service of each device node. The device start request is sent by an application process through the following way: The application process checks whether a device node to be started has been registered in a second VFS library, wherein the second VFS library is a VFS library of the application process; if not, the application process checks a main thread RPC service; The application process sends the device start request to the driver main thread based on the main thread RPC service.

7. The method of claim 2, wherein, The application process checks an RPC service of the device node to be started at the same time of checking the main thread RPC service; ​ ​ 8. The method of claim 7, wherein, ​ After the application process receives the device starting result fed back by the driver main thread, if the device starting result is successful, the application process sends the device operation request to the device sub-thread based on the RPC service of the device node to be started.

9. The method of claim 1, wherein, The method further comprises: After the driver main thread determines that the first RPC message is a device closing request, the driver main thread ends the device sub-thread of the corresponding device node; After the driver main thread ends the device sub-thread of the corresponding device node, the driver main thread closes the device node.

10. A device driver apparatus of a microkernel architecture, wherein, The device comprises a driver main thread and a device sub-thread; the operating system starts the driver main thread in response to a starting instruction, and does not start the device sub-thread; The driver main thread is configured to receive a first RPC message through an RPC service, and start a device sub-thread of a corresponding device node after determining that the first RPC message is a device starting request; The device sub-thread is configured to receive a second RPC message through the RPC service after being started, and perform a corresponding device operation on the device node after determining that the second RPC message is a device operation request.

11. An electronic device comprising: A processor and a memory; The processor is configured to execute the steps of the method according to any one of claims 1 to 9 by calling programs or instructions stored in the memory. 12.A non-transitory computer readable storage medium storing programs or instructions, which cause a computer to execute the steps of the method according to any one of claims 1 to 9.

Images