WO2023274376A1

WO2023274376A1 - Device drive method and apparatus for micro-kernel architecture, and electronic device and storage medium

Info

Publication number: WO2023274376A1
Application number: PCT/CN2022/102981
Authority: WO
Inventors: 梁超众; 童武胜; 刘勇锋; 毛熠璐
Original assignee: 阿里巴巴（中国）有限公司
Priority date: 2021-06-30
Filing date: 2022-06-30
Publication date: 2023-01-05
Also published as: CN115562731A

Abstract

The embodiments of the present disclosure relate to a device drive method and apparatus for a micro-kernel architecture, and an electronic device and a storage medium. In at least one embodiment of the present disclosure, a master-slave thread architecture mode including a drive master thread and a device sub-thread is used; when an operation system is started, only the drive master thread is started, and the device sub-thread is not started, such that system resources consumed by the device sub-thread are reduced; in addition, the drive master thread and the device sub-thread provide a device drive service by means of RPC; and specifically, when a first RPC message received by the drive master thread is a device start request, the drive master thread starts the device sub-thread of a device node, and then after determining that a received second RPC message is a device operation request, the device sub-thread performs a corresponding operation on the device node, thereby solving the problem of an application being unable to directly call a device driver in the current micro-kernel architecture.

Description

Device driver method, device, electronic device and storage medium of microkernel architecture

This application claims the priority of the Chinese patent application with the application number 202110734252.7 and the title of the invention "microkernel architecture device driving method, device, electronic device and storage medium" submitted on June 30, 2021, the entire content of which is incorporated by reference in this application.

technical field

The embodiments of the present disclosure relate to the field of computer technology, and in particular to a device driving method, device, electronic device and non-transitory computer-readable storage medium of a microkernel architecture.

Background technique

An operating system (Operation System, OS) is a computer program that manages computer hardware and software resources. A system call is the smallest functional unit of the operating system. The system call divides the operating system into a kernel state (which can be understood as kernel space) and a user state (which can be understood as user space). The kernel is a special software program of the operating system that runs directly on the hardware. It can be understood as a bridge connecting the application program and the hardware, and is used to control the hardware resources of the computer, such as coordinating the Central Processing Unit (Central Processing Unit, CPU) resources. , allocate memory resources and provide a stable environment for the application to run. User mode can be understood as providing space for applications to run. In order for applications to access resources managed by the kernel, such as CPU resources, memory resources, and I/O (Input/Output, input/output) resources, the kernel needs to provide a set of common access interfaces, which are system calls.

Currently, there are two types of kernel architectures of operating systems: a macrokernel architecture and a microkernel architecture. Figure 1 shows a schematic diagram of the architecture of the macrokernel and a schematic diagram of the architecture of the microkernel. It can be seen from Figure 1 that in the macrokernel architecture, components, applications and device drivers run in the kernel mode, so components and applications can directly call device drivers. However, in the microkernel architecture, device drivers run in user mode, such as process 1, and components and applications run in user mode process 2. In this way, components and applications cannot directly call device drivers. Therefore, it is urgent to provide A device driver scheme for microkernel architecture.

Contents of the invention

In order to solve at least one problem in the prior art, at least one embodiment of the present disclosure provides a device driving method, device, electronic device and non-transitory computer-readable storage medium of a microkernel architecture.

In the first aspect, the embodiment of the present disclosure proposes a device driving method of a microkernel architecture, wherein the operating system starts the driving main thread in response to the startup command, and does not start the device sub-thread. The device driving method includes:

Drive the main thread to receive the first RPC message through the RPC service;

After the main thread of the driver determines that the first RPC message is a device start request, start the device sub-thread of the corresponding device node;

After the device sub-thread is started, it receives the second RPC message through the RPC service;

After the device sub-thread determines that the second RPC message is a device operation request, it performs a corresponding device operation on the device node.

In some embodiments, before the driver main thread receives the first RPC message through the RPC service, the device driver method further includes:

Drive the main thread to register and start the main thread RPC service;

After the main thread of the driver starts the RPC service of the main thread, it registers the RPC service of one or more device nodes and registers each device node.

In some embodiments, after the main thread of the driver determines that the first RPC message is a device start request, start the device sub-thread of the corresponding device node, including:

After the driving main thread determines that the first RPC message is a device startup request, open the device node corresponding to the device startup request;

After the main thread of the driver opens the device node, it starts the device sub-thread of the device node.

After determining that the first RPC message is a device startup request, the driving main thread invokes a thread creation API provided by the operating system to create a device sub-thread of a device node corresponding to the device startup request.

In some embodiments, the device driving method also includes:

The device sub-thread opens the corresponding device node after startup;

After the device sub-thread opens the device node and determines that the second RPC message is a device operation request, it performs a corresponding device operation on the device node.

In some embodiments, registering the RPC service of one or more device nodes and registering each device node includes:

The driver main thread scans the driver list to obtain one or more device types and the device nodes corresponding to each device type;

Drive the main thread to register the RPC service of each device node;

The driver main thread registers each device node after registering the RPC service of each device node.

In some embodiments, registering each device node includes:

Register each device node with the first VFS library, where the first VFS library is the VFS library that drives the process where the main thread resides; or, register each device node with the PM process.

In some embodiments, the device start request is sent by the application process in the following manner:

The application process searches whether the device node to be started is registered in the second VFS library, wherein the second VFS library is the VFS library of the application process; if not registered, the application process searches for the main thread RPC service;

The application process sends a device startup request to the driver main thread based on the main thread RPC service.

In some embodiments, the application process searches for the RPC service of the main thread RPC service while also searching for the RPC service of the device node to be started;

After the application process receives the device startup result fed back by the driver main thread, if the device startup 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.

In some embodiments, the driver main thread registers in the PM process and starts the main thread RPC service; the application process searches for the main thread RPC service in the PM process.

In some embodiments, the device driving method also includes:

After the main thread is driven to determine that the first RPC message is a device shutdown request, the device sub-thread of the corresponding device node is terminated;

The driver main thread closes the device node after ending the device sub-thread of the corresponding device node.

In the second aspect, the embodiment of the present disclosure also proposes a device driving device with a microkernel architecture, wherein the device driving device includes: a driving main thread and a device sub-thread; the operating system starts the driving main thread in response to a start command, and does not start Device sub-thread;

Driving the main thread, used to receive the first RPC message through the RPC service, and after determining that the first RPC message is a device startup request, start the device sub-thread of the corresponding device node;

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

In the third aspect, the embodiment of the present disclosure also proposes an electronic device, including: a processor and a memory; the processor is used to execute the microkernel architecture described in the first aspect by calling the program or instruction stored in the memory. The steps of a device driver method.

In the fourth aspect, the embodiments of the present disclosure also provide a non-transitory computer-readable storage medium for storing programs or instructions, and the programs or instructions cause the computer to execute the device driving method of the microkernel architecture as described in the first aspect. step.

It can be seen that in at least one embodiment of the present disclosure, the master-slave thread architecture mode of the driver main thread and the device sub-thread is adopted. When the operating system is started, only the driver main thread is started, and the device sub-thread is not started, reducing the impact of the device sub-thread. consumption of system resources; and, the driver main thread and the device sub-thread provide device driver services through RPC, specifically, when the first RPC message received by the driver main thread is a device start request, the driver main thread restarts the device node The device sub-thread, and then the device sub-thread determines that the received second RPC message is a device operation request, and then performs corresponding operations on the device node, so as to solve the problem that the application cannot directly call the device driver in the current microkernel architecture.

Description of drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the following will briefly introduce the drawings that need to be used in the embodiments or the description of the prior art. Obviously, the drawings in the following description are only some of the present disclosure. Embodiments, those of ordinary skill in the art can also obtain other drawings based on these drawings.

Fig. 1 is a schematic diagram of a macro kernel architecture and a schematic diagram of a micro kernel architecture;

FIG. 2 is a flowchart of a device driving method of a microkernel architecture provided by an embodiment of the present disclosure;

Fig. 3 is a flow chart of starting a device sub-thread provided by an embodiment of the present disclosure;

FIG. 4 is a flow chart of another startup device sub-thread provided by an embodiment of the present disclosure;

FIG. 5 is an interaction diagram of a device driving method of a microkernel architecture provided by an embodiment of the present disclosure;

FIG. 6 is an exemplary block diagram of a device driver device of a microkernel architecture provided by an embodiment of the present disclosure;

Fig. 7 is an exemplary block diagram of an electronic device provided by an embodiment of the present disclosure.

detailed description

In order to more clearly understand the above objects, features and advantages of the present disclosure, the present disclosure will be further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the described embodiments are some of the embodiments of the present disclosure, but not all of the embodiments. The specific embodiments described here are only used to explain the present disclosure, but not to limit the present disclosure. All other embodiments obtained by persons of ordinary skill in the art based on the described embodiments of the present disclosure belong to the protection scope of the present disclosure.

It should be noted that in this article, relative terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply these No such actual relationship or order exists between entities or operations.

A microkernel is an operating system kernel capable of providing necessary services, including but not limited to tasks, threads, Inter-Process Communication (IPC, Inter-Process Communication) and memory management. All services (including device drivers) run in user mode, and handling these services is the same as handling any other program, because each service only runs in its own address space.

In order to solve at least one problem 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 a microkernel architecture, using a master-slave thread architecture The pattern designs the device driver loading method and the application programming interface (Application Programming Interface, API) that the device driver provides external services in detail. Wherein, the loading of the device driver includes: RPC service registration of the device node and registration of the device node. The external services provided by the device driver include: device start request (open), device close request (close) and device operation request, wherein the device operation request includes but not limited to: write request (write), read request (read), input/ Output requests (ioctl), etc.

In at least one embodiment of the present disclosure, the master-slave thread architecture mode of the driver main thread and the device sub-thread is adopted. When the operating system is started, only the driver main thread is started, and the device sub-thread is not started, reducing the impact of the device sub-thread on system resources. consumption; and, the driving main thread and the device sub-thread provide device driver services through RPC, specifically, when the first RPC message received by the driving main thread is a device startup request, the driving main thread restarts the device sub-thread of the device node thread, and then the device sub-thread determines that the received second RPC message is a device operation request, and then performs corresponding operations on the device node, so as to solve the problem that the application cannot directly call the device driver in the current microkernel architecture.

Fig. 2 is a flowchart of a device driving method of a microkernel architecture provided by an embodiment of the present disclosure. When the operating system using the microkernel architecture is started, for example, the operating system receives a start command, such as the command generated by the user pressing the power button. The consumption of hardware and software resources of the operating system by device sub-threads. In some embodiments, there may be multiple device sub-threads, and each device sub-thread corresponds to a device node. No matter how many device sub-threads there are, these device sub-threads are not started when the operating system is started.

After the operating system starts the driving main thread, in step 201, the driving main thread receives a first RPC message through the RPC service.

Among them, the RPC (Remote Procedure Call, remote procedure call) service is a way of interaction between different processes in the microservice architecture. Although the application in the microservice architecture cannot directly call the device driver, the application process can communicate with the device through RPC. The process where the driver is located sends the first RPC message, so that the main thread of the driver can provide the device driver service through RPC.

In step 202, after determining that the first RPC message is a device start request, the driving main thread starts the device sub-thread of the corresponding device node.

The device driver service provided by the driver main thread through RPC includes a device start request (open), so that the application process can send a device start request to the driver main thread through RPC, and the device start request carries the information of the device node to be started .

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

It can be seen that the startup 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 unused device node can be reduced. , the consumption of hardware and software resources of the operating system by device sub-threads.

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

After the device sub-thread is started, it can provide device driver services through RPC. Device driver services are, for example, device operation requests. Device operation requests include but are not limited to: write requests (write), read requests (read), input/output requests ( ioctl) etc. In this way, the application process can send a device operation request to the device sub-thread through RPC.

It should be noted that, after the device sub-thread is started, the second RPC messages received are all directed at the device node corresponding to the device sub-thread.

In step 204, after the device sub-thread determines that the second RPC message is a device operation request, it 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; if the device operation request is an input/output request, the device The child thread performs input/output operations on the device node.

It can be seen that the embodiment adopts the master-slave thread architecture mode of driving the main thread and the device sub-thread. When the operating system is started, only the driving main thread is started, and the device sub-thread is not started, so as to reduce the consumption of system resources by the device sub-thread; and , the driver main thread and the device sub-thread provide device driver services through RPC. Specifically, when the first RPC message received by the driver main thread is a device startup request, the driver main thread restarts the device sub-thread of the device node, and then the After the device sub-thread determines that the received second RPC message is a device operation request, it performs a corresponding operation on the device node to solve the problem that the application cannot directly call the device driver in the current microkernel architecture.

In some embodiments, before the driving main thread receives the first RPC message through the RPC service, the driving main thread needs to register and start the main thread RPC service first, and then receive the first RPC message through the main thread RPC service.

After the main thread of the driver registers and starts the RPC service of the main thread, it can register the RPC service of one or more device nodes and register each device node. In some embodiments, the driver main 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 may receive the second RPC message through the RPC service of the device node corresponding to the device sub-thread after being started.

In some embodiments, after the main driver thread determines that the first RPC message is a device start request, there are multiple ways to start the device sub-thread of the corresponding device node.

For example, FIG. 3 is a flow chart of starting a device sub-thread provided by an embodiment of the present disclosure. In step 301, the driving main thread receives a device startup request. In this step, the main driving thread waits to receive the first RPC message, and after the main driving thread determines that the received first RPC message is a device startup request, step 302 is executed.

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

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

As another example, FIG. 4 is another flowchart of starting a device sub-thread provided by an embodiment of the present disclosure. Step 401 is the same as step 301 in FIG. 3 and will not be repeated here.

In step 402, the driving main thread calls the create thread API ( ) provided by the operating system to create a device sub-thread of the device node corresponding to the device start request. In this embodiment, different from the embodiment in FIG. 3 , after receiving the device start request, the main driver thread does not open the device node first and then start the device sub-thread of the device node, but directly calls the create thread API to create the device node The device child thread.

In step 403, the device sub-thread opens the corresponding device node after being started. The difference from the embodiment in FIG. 3 is that the device node is not opened by the main thread of the driver, but by the sub-thread of the device. Specifically, the device sub-line opens the device node by pointing the ops (operation method) pointer to the member of the ops structure: open, that is, ops->open.

In some embodiments, when driving the main thread to register each device node, each device node can be registered with the first VFS (Virtual File System, virtual file system) library, wherein the first VFS library is the process where the main thread is driven VFS library; Alternatively, the driver main thread can register each device node with the PM (Pass Manager, path management) process.

In some embodiments, the application process checks whether the device node to be started is registered in the second VFS library, wherein the second VFS library is the VFS library of the application process; if not registered, the application process searches for the main thread RPC service. In some embodiments, the main thread RPC service is registered and started by the driver main thread in the PM process. Therefore, the application process searches the main thread RPC service in the PM process, and the PM process feeds back the query result to the application process.

After the application process finds the main thread RPC service, it can send a device startup request to the driver main thread based on the main thread RPC service.

In some embodiments, the application process may also search for the RPC service of the device node to be started while searching for the RPC service of the main thread. 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. Therefore, the application process searches for the main thread RPC service in the PM process. service and the RPC service of the device node to be started, and the PM process feeds back the query result to the application process.

In some embodiments, the device driver service provided by the main driver thread through RPC includes a device shutdown request (open). In this way, the application process can send a device shutdown request to the driver main thread through RPC, and the device startup request carries the device shutdown request. The information of the closed device node or the result of device startup, so that the main thread of the driver can determine the device node corresponding to the device shutdown request.

After the main driving thread determines that the first RPC message is a device close request, it terminates the device sub-thread of the corresponding device node. The driver main thread closes the device node after ending the device sub-thread of the corresponding device node. In some embodiments, the driving main thread closes the device node by pointing the ops (operation method) pointer to the member of the ops structure: close, that is, ops->close.

In combination with the descriptions of the above method embodiments, FIG. 5 is an interaction diagram of a device driving method of a microkernel architecture provided by an embodiment of the present disclosure. It should be noted that FIG. 5 is only some embodiments of the present disclosure, not all of them. Example.

In FIG. 5 , for ease of description, only one device sub-thread is shown. Those skilled in the art can understand that there may be multiple device sub-threads, and the interaction process is similar.

In Figure 5, when the operating system using the microkernel architecture is started, for example, the operating system receives a start command, such as the command generated by the user pressing the power button, the operating system responds to the start command and only starts the main thread of the driver, not the Device sub-threads reduce the consumption of operating system software and hardware resources by device sub-threads.

In FIG. 5 , after the main thread of the driver is started, the RPC service of the main thread is registered and started in the PM process, and the RPC service of the device node and the device node are registered in the PM process. After completing the above registration work, the driver main thread can wait for the RPC message.

In Fig. 5, the application process searches whether the device node to be started is registered in the second VFS library, wherein the second VFS library is the VFS library of the application process; if not registered, the application process performs RPC service in the PM process Query, the RPC service query includes finding the main thread RPC service and the RPC service of the device node to be started.

The PM process feeds back the query result to the application process, wherein the query result includes: main thread RPC service information and service information of the device node to be started. After the application process obtains the query result, it sends a device startup request to the driver main thread based on the main thread RPC service, and the device startup request carries the information of the device node (such as the name of the device node).

In Figure 5, after the main thread of the driver receives the device startup request, it determines the corresponding device node based on the device node information carried in the device startup request, and then points the ops (operation method) pointer to the member of the ops structure: open , that is, ops->open, to open the device node.

After the main driver thread opens the device node, it starts the device sub-thread of the device node, and feeds back the device startup 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 starting.

In Figure 5, after the application process receives the device startup result fed back from the main thread, if the device startup 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.

After the device sub-thread receives the device operation request, it performs the 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; if the device operation request is an input/output request, the device The child thread performs input/output operations on the device node.

In FIG. 5 , the application process can send a device shutdown request to the main driver thread, and the device startup request carries the information of the device node to be shutdown or the device startup result, so that the driver main thread can determine the device node corresponding to the device shutdown request.

After receiving the device close request, the driver main thread ends the device sub-thread of the corresponding device node. After the main thread of the driver finishes the device sub-thread of the corresponding device node, it closes the device node by pointing the ops (operation method) pointer to the member of the ops structure: close, that is, ops->close.

It can be seen that the interaction process of the device driver method of the microkernel architecture shown in Figure 5 adopts the master-slave thread architecture mode of the driver main thread and the device sub-thread. When the operating system starts, only the driver main thread is started, and the device sub-thread is not started. threads, reducing the consumption of system resources by device sub-threads; and, the main driver thread and device sub-threads provide device driver services through RPC, specifically, when the main driver thread receives a device start request, the main driver thread restarts the device node The device sub-thread, and then the device sub-thread performs corresponding operations on the device node based on the received device operation request, so as to solve the problem that the application cannot directly call the device driver in the current microkernel architecture.

FIG. 6 is a device driver of a microkernel architecture provided by an embodiment of the present disclosure. The device driver includes: a driving main thread 61 and a device sub-thread 62 . The operating system that adopts the microkernel architecture responds to the startup command and starts the driver main thread 61, and does not start the device sub-thread 62. The device driver may include multiple device sub-threads 62, and each device sub-thread 62 corresponds to a device node.

The main thread 61 is driven to receive the first RPC message through the RPC service, and after determining that the first RPC message is a device start request, start the device sub-thread 62 of the corresponding device node.

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

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

In some embodiments, after the main driver thread 61 determines that the first RPC message is a device start request, it starts the device sub-thread 62 of the corresponding device node, which specifically includes: after determining that the first RPC message is a device start request, opening the device start request The corresponding device node; after opening the device node, start the device sub-thread 62 of the device node.

In some embodiments, after the main driver thread 61 determines that the first RPC message is a device start request, it starts the device sub-thread 62 of the corresponding device node, which specifically includes: after determining that the first RPC message is a device start request, calling the operating system to provide Create a thread API to create the device sub-thread 62 of the device node corresponding to the device start request.

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

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

In some embodiments, driving the main thread 61 to register each device node specifically includes: registering each device node with the first VFS library, wherein the first VFS library is the VFS library of the process where the main thread is driven; or, registering each device node with the PM A process registers each device node.

The application process searches whether the device node to be started is registered in the second VFS library, wherein the second VFS library is the VFS library of the application process; if it is not registered, the application process searches for the main thread RPC service; the application process is based on the main thread RPC The service sends a device start request to the driver main thread.

In some embodiments, while the application process searches for the RPC service of the main thread, it also searches for the RPC service of the device node to be started. After the application process receives the device startup result fed back by the driver main thread, if the device startup 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.

In some embodiments, the driving main thread 61 registers in the PM process and starts the main thread RPC service. The application process looks for the main thread RPC service in the PM process.

In some embodiments, the driving main thread 61 is also used to end the device sub-thread 62 of the corresponding device node after determining that the first RPC message is a device closing request; the driving main thread 61 ends the device sub-thread 62 of the corresponding device node After that, close the device node.

For the details of the above device embodiments, reference may be made to the details of the method examples, and details are not repeated here to avoid repetition.

Fig. 7 is a schematic structural diagram of an electronic device provided by an embodiment of the present disclosure. As shown in FIG. 7 , the electronic device includes: at least one processor 71 , at least one memory 72 and at least one communication interface 73 . Various components in the electronic device are coupled together via a bus system 74 . The communication interface 73 is used for information transmission with external devices. Understandably, the bus system 74 is used to realize connection communication between these components. In addition to the data bus, the bus system 74 also includes a power bus, a control bus and a status signal bus. However, for clarity of illustration, the various buses are labeled as bus system 74 in FIG.

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

In some embodiments, memory 72 stores the following elements, executable units or data structures, or subsets thereof, or extensions thereof: operating system and application programs.

Among them, the operating system includes various system programs, such as framework layer, core library layer, driver layer, etc., for realizing various basic tasks and processing hardware-based tasks. The application program includes various application programs, such as a media player (Media Player), a browser (Browser), etc., and is used to implement various application tasks. The program for implementing the device driving method of the microkernel architecture provided by the embodiments of the present disclosure may be included in an application program or an operating system.

In the embodiment of the present disclosure, the processor 71 calls the program or instruction stored in the memory 72, specifically, the program or instruction stored in the application program, and the processor 71 is used to execute the microkernel architecture provided by the embodiment of the present disclosure. The steps of each embodiment of the device driving method.

The device driving method of the microkernel architecture provided by the embodiment of the present disclosure may be applied to the processor 71 or implemented by the processor 71 . The processor 71 may be an integrated circuit chip, which has a signal processing capability. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor 71 or instructions in the form of software. The above-mentioned processor 71 can be a general-purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a ready-made programmable gate array (Field Programmable Gate Array, FPGA) or other Programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. A general-purpose processor may be a microprocessor, or the processor may be any conventional processor, or the like.

The steps of the device driving method of the microkernel architecture provided by the embodiments of the present disclosure may be directly implemented by a hardware decoding processor, or executed by a combination of hardware and software units in the decoding processor. The software unit may be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register. The storage medium is located in the memory 72, and the processor 71 reads the information in the memory 72, and completes the steps of the method in combination with its hardware.

It should be noted that, for the sake of simple description, the aforementioned method embodiments are expressed as a series of action combinations, but those skilled in the art can understand that the embodiments of the present disclosure are not limited by the described action sequence. limitations, because certain steps may be performed in other orders or simultaneously according to embodiments of the present disclosure. In addition, those skilled in the art can understand that the embodiments described in the specification are all optional embodiments.

The embodiment of the present disclosure also proposes a non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium stores programs or instructions, and the programs or instructions cause the computer to execute various implementations of the device driver method such as the microkernel architecture. In order to avoid repeated description, the steps of the example are not repeated here.

It should be noted that, in this document, the term "comprising", "comprising" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article or apparatus comprising a set of elements includes not only those elements, It also includes other elements not expressly listed, or elements inherent in the process, method, article, or device. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional same elements in the process, method, article or apparatus comprising the element.

Those skilled in the art will appreciate that although some of the embodiments described herein include some features included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of the present disclosure. And form different embodiments.

Those skilled in the art can understand that the description of each embodiment has its own emphases, and for parts not described in detail in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

Although the embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure. within the bounds of the requirements.

Claims

A device driving method of a microkernel architecture, wherein the operating system starts a driving main thread in response to a start instruction, and does not start a device sub-thread, and the method includes:

The main thread of the drive receives the first RPC message through the RPC service;

After the main driving thread determines that the first RPC message is a device start request, start the device sub-thread of the corresponding device node;

After the device sub-thread is started, it receives the second RPC message through the RPC service;

After the device sub-thread determines that the second RPC message is a device operation request, it performs a corresponding device operation on the device node.
The method according to claim 1, wherein, before the driving main thread receives the first RPC message through the RPC service, the method further comprises:

The driver main thread registers and starts the main thread RPC service;

After the main thread of the driver starts the RPC service of the main thread, it registers the RPC service of one or more device nodes and registers each of the device nodes.
The method according to claim 1, wherein after the main driving thread determines that the first RPC message is a device startup request, starting the device sub-thread of the corresponding device node includes:

After the main driving thread determines that the first RPC message is a device startup request, it opens a device node corresponding to the device startup request;

After the main driver thread opens the device node, it starts the device sub-thread of the device node.
The method according to claim 1, wherein after the main driving thread determines that the first RPC message is a device startup request, starting the device sub-thread of the corresponding device node includes:

After the main driver thread determines that the first RPC message is a device startup request, it invokes a thread creation API provided by the operating system to create a device sub-thread of a device node corresponding to the device startup request.
The method according to claim 4, wherein the method further comprises:

The device sub-thread opens the corresponding device node after starting;

After the device sub-thread opens the device node and determines that the second RPC message is a device operation request, it performs a corresponding device operation on the device node.
The method according to claim 2, wherein said registering the RPC service of one or more device nodes and registering each of said device nodes comprises:

The driver main thread scans the driver list to obtain one or more device types and device nodes corresponding to each device type;

The driving main thread registers the RPC service of each of the device nodes;

The driver main thread registers each of the device nodes after registering the RPC service of each of the device nodes.
The method according to claim 2, wherein the device startup request is sent by the application process in the following manner:

The application process searches whether the device node to be started is registered in the second VFS storehouse, wherein the second VFS storehouse is the VFS storehouse of the application process; if not registered, the application process searches for the main thread RPC Serve;

The application process sends the device startup request to the driver main thread based on the main thread RPC service.
The method according to claim 7, wherein, while the application process searches for the RPC service of the main thread, it also searches for the RPC service of the device node to be started;

After the application process receives the device startup result fed back by the driving main thread, if the device startup result is successful, the application process sends the device sub-thread based on the RPC service of the device node to be started The device operation request.
The method according to claim 1, wherein the method further comprises:

After the main driving thread determines that the first RPC message is a device closing request, end the device sub-thread of the corresponding device node;

The main driving thread closes the device node after finishing the device sub-thread of the corresponding device node.
A device driving device with a microkernel architecture, wherein the device includes: a driving main thread and a device sub-thread; the operating system starts the driving main thread in response to a start command, and does not start the device sub-thread;

The driving main thread is used to receive the first RPC message through the RPC service, and after determining that the first RPC message is a device startup request, start the device sub-thread of the corresponding device node;

The device sub-thread is configured to receive a second RPC message through the RPC service after startup, and perform a corresponding device operation on the device node after determining that the second RPC message is a device operation request.
An electronic device comprising: a processor and a memory;

The processor is used to execute the steps of the method according to any one of claims 1 to 9 by invoking the programs or instructions stored in the memory.
A non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium stores a program or an instruction, and the program or instruction causes a computer to execute the steps of the method according to any one of claims 1 to 9.