WO2023274376A1 - 微内核架构的设备驱动方法、装置、电子设备和存储介质 - Google Patents

微内核架构的设备驱动方法、装置、电子设备和存储介质 Download PDF

Info

Publication number
WO2023274376A1
WO2023274376A1 PCT/CN2022/102981 CN2022102981W WO2023274376A1 WO 2023274376 A1 WO2023274376 A1 WO 2023274376A1 CN 2022102981 W CN2022102981 W CN 2022102981W WO 2023274376 A1 WO2023274376 A1 WO 2023274376A1
Authority
WO
WIPO (PCT)
Prior art keywords
thread
rpc
sub
node
main
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2022/102981
Other languages
English (en)
French (fr)
Inventor
梁超众
童武胜
刘勇锋
毛熠璐
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba China Co Ltd
Original Assignee
Alibaba China Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba China Co Ltd filed Critical Alibaba China Co Ltd
Publication of WO2023274376A1 publication Critical patent/WO2023274376A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files

Definitions

  • 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.
  • An operating system 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.
  • the kernel needs to provide a set of common access interfaces, which are system calls.
  • FIG. 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.
  • 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.
  • 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:
  • 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;
  • the device sub-thread After the device sub-thread is started, it receives the second RPC message through the RPC service;
  • the device sub-thread 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 device driver method before the driver main thread receives the first RPC message through the RPC service, the device driver method further includes:
  • the main thread of the driver 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.
  • start the device sub-thread of the corresponding device node including:
  • 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;
  • start the device sub-thread of the corresponding device node including:
  • the driving main thread 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.
  • the device driving method also includes:
  • the device sub-thread opens the corresponding device node after startup
  • the device sub-thread 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.
  • 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;
  • the driver main thread registers each device node after registering the RPC service of each device node.
  • registering each device node includes:
  • 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.
  • 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;
  • the application process 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.
  • 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.
  • the device driving method also includes:
  • 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.
  • 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.
  • 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.
  • 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.
  • the master-slave thread architecture mode of the driver main thread and the device sub-thread is adopted.
  • 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.
  • 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.
  • 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.
  • 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.
  • IPC Inter-Process Communication
  • IPC Inter-Process Communication
  • 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.
  • 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.
  • the master-slave thread architecture mode of the driver main thread and the device sub-thread is adopted.
  • 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.
  • 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.
  • the operating system using the microkernel architecture receives a start command, such as the command generated by the user pressing the power button.
  • 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.
  • step 201 the driving main thread receives a first RPC message through the RPC service.
  • the RPC (Remote Procedure Call, remote procedure call) service is a way of interaction between different processes in the microservice architecture.
  • 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.
  • 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 .
  • the driver main thread 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.
  • the startup of the device sub-thread is controlled by the driver main thread.
  • 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.
  • step 203 the device sub-thread receives the second RPC message through the RPC service after being started.
  • 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.
  • the application process can send a device operation request to the device sub-thread through RPC.
  • the second RPC messages received are all directed at the device node corresponding to the device sub-thread.
  • 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.
  • 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.
  • the embodiment adopts the master-slave thread architecture mode of driving the main thread and the device sub-thread.
  • 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.
  • 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.
  • the driving main thread 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.
  • the main thread of the driver 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.
  • 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.
  • 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.
  • FIG. 3 is a flow chart of starting a device sub-thread provided by an embodiment of the present disclosure.
  • the driving main thread receives a device startup request.
  • 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.
  • the driving main thread opens the device node corresponding to the device start request.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the main driver thread after receiving the device start request, 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.
  • the device sub-thread opens the corresponding device node after being started.
  • the device node is not opened by the main thread of the driver, but by the sub-thread of the device.
  • 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.
  • the device sub-thread 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.
  • each device node when driving the main thread to register 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;
  • the driver main thread can register each device node with the PM (Pass Manager, path management) process.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the application process 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.
  • the device driver service provided by the main driver thread through RPC includes a device shutdown request (open).
  • 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 main driving thread 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.
  • 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.
  • 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.
  • 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.
  • the operating system 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.
  • a start command such as the command generated by the user pressing the power button
  • the driver main thread can wait for the RPC message.
  • 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.
  • 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).
  • 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.
  • the device sub-thread 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.
  • 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.
  • the driver main thread 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.
  • 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.
  • the operating system starts, only the driver main thread is started, and the device sub-thread is not started.
  • 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.
  • 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.
  • 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.
  • the main driver thread 61 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.
  • 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.
  • 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.
  • 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 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 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.
  • 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.
  • 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.
  • 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.
  • Fig. 7 is a schematic structural diagram of an electronic device provided by an embodiment of the present disclosure.
  • 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.
  • 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.
  • 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.
  • memory 72 stores the following elements, executable units or data structures, or subsets thereof, or extensions thereof: operating system and application programs.
  • 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.
  • 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 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

本公开实施例涉及微内核架构的设备驱动方法、装置、电子设备和存储介质。本公开的至少一个实施例中，采用驱动主线程和设备子线程的主从线程架构模式，在操作系统启动时，仅启动驱动主线程，而不启动设备子线程，减少设备子线程对系统资源的消耗；并且，驱动主线程和设备子线程通过RPC方式提供设备驱动服务，具体地，当驱动主线程接收到的第一RPC消息为设备启动请求后，驱动主线程再启动设备节点的设备子线程，进而由设备子线程确定接收到的第二RPC消息为设备操作请求后，对设备节点进行对应的操作，解决目前的微内核架构中，应用无法直接调用设备驱动的问题。

Description

微内核架构的设备驱动方法、装置、电子设备和存储介质
本申请要求2021年06月30日递交的申请号为202110734252.7、发明名称为“微内核架构的设备驱动方法、装置、电子设备和存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本公开实施例涉及计算机技术领域，具体涉及一种微内核架构的设备驱动方法、装置、电子设备和非暂态计算机可读存储介质。
背景技术
操作系统(Operation System，OS)是管理计算机硬件与软件资源的计算机程序。系统调用是操作系统的最小功能单位，系统调用将操作系统分为内核态(可以理解为内核空间)和用户态(可以理解为用户空间)。内核是操作系统的一种特殊的软件程序，直接运行在硬件上，可以理解为连接应用程序和硬件的桥梁，用于控制计算机的硬件资源，例如协调中央处理单元(Central Processing Unit，CPU)资源、分配内存资源并提供稳定的环境供应用程序运行。用户态可以理解为提供应用程序运行的空间。为了使应用程序访问到内核管理的资源，例如CPU资源、内存资源、I/O(Input/Output，输入/输出)资源，内核需提供一组通用的访问接口，这些接口即为系统调用。
目前，操作系统的内核架构有两种：宏内核架构和微内核架构。图1示出了宏内核的架构示意图和微内核架构示意图，由图1可见，在宏内核架构中组件、应用和设备驱动运行于内核态，因此，组件和应用可以直接调用设备驱动。而在微内核架构中，设备驱动运行于用户态，例如运行于进程1中，组件和应用运行于用户态的进程2中，这样，组件和应用无法直接调用设备驱动，为此，亟需提供一种微内核架构的设备驱动方案。
发明内容
为了解决现有技术存在的至少一个问题，本公开的至少一个实施例提供了一种微内核架构的设备驱动方法、装置、电子设备和非暂态计算机可读存储介质。
第一方面，本公开实施例提出一种微内核架构的设备驱动方法，其中，操作系统响应启动指令而启动驱动主线程，且不启动设备子线程，该设备驱动方法包括：
驱动主线程通过RPC服务接收第一RPC消息；
驱动主线程确定第一RPC消息为设备启动请求后，启动对应的设备节点的设备子线程；
设备子线程在启动后通过RPC服务接收第二RPC消息；
设备子线程确定第二RPC消息为设备操作请求后，对设备节点进行对应的设备操作。
在一些实施例中，驱动主线程通过RPC服务接收第一RPC消息之前，该设备驱动方法还包括：
驱动主线程注册并启动主线程RPC服务；
驱动主线程在启动主线程RPC服务后，注册一个或多个设备节点的RPC服务并将注册每个设备节点。
在一些实施例中，驱动主线程确定第一RPC消息为设备启动请求后，启动对应的设备节点的设备子线程，包括：
驱动主线程确定第一RPC消息为设备启动请求后，打开设备启动请求对应的设备节点；
驱动主线程在打开设备节点后，启动设备节点的设备子线程。
在一些实施例中，驱动主线程确定第一RPC消息为设备启动请求后，启动对应的设备节点的设备子线程，包括：
驱动主线程确定第一RPC消息为设备启动请求后，调用操作系统提供的创建线程API，以创建设备启动请求对应的设备节点的设备子线程。
在一些实施例中，该设备驱动方法还包括：
设备子线程在启动后打开对应的设备节点；
设备子线程在打开设备节点后，且确定第二RPC消息为设备操作请求后，对设备节点进行对应的设备操作。
在一些实施例中，注册一个或多个设备节点的RPC服务并将注册每个设备节点，包括：
驱动主线程扫描驱动列表，得到一个或多个设备类型以及每个设备类型对应的设备节点；
驱动主线程注册每个设备节点的RPC服务；
驱动主线程在注册每个设备节点的RPC服务后注册每个设备节点。
在一些实施例中，注册每个设备节点包括：
向第一VFS库注册每个设备节点，其中，第一VFS库为驱动主线程所在进程的VFS库；或，向PM进程注册每个设备节点。
在一些实施例中，设备启动请求由应用进程通过如下方式发送：
应用进程在第二VFS库中查找待启动的设备节点是否已注册，其中，第二VFS库为应用进程的VFS库；若未注册，则应用进程查找主线程RPC服务；
应用进程基于主线程RPC服务向驱动主线程发送设备启动请求。
在一些实施例中，应用进程查找主线程RPC服务的同时还查找待启动的设备节点的RPC服务；
应用进程接收到驱动主线程反馈的设备启动结果后，若设备启动结果为成功，则应 用进程基于待启动的设备节点的RPC服务向设备子线程发送设备操作请求。
在一些实施例中，驱动主线程在PM进程中注册并启动主线程RPC服务；应用进程在PM进程中查找主线程RPC服务。
在一些实施例中，该设备驱动方法还包括：
驱动主线程确定第一RPC消息为设备关闭请求后，结束对应的设备节点的设备子线程；
驱动主线程在结束对应的设备节点的设备子线程后，关闭设备节点。
第二方面，本公开实施例还提出一种微内核架构的设备驱动装置，其中，该设备驱动装置包括：驱动主线程和设备子线程；操作系统响应启动指令而启动驱动主线程，且不启动设备子线程；
驱动主线程，用于通过RPC服务接收第一RPC消息，并确定第一RPC消息为设备启动请求后，启动对应的设备节点的设备子线程；
设备子线程，用于在启动后通过RPC服务接收第二RPC消息，并确定第二RPC消息为设备操作请求后，对设备节点进行对应的设备操作。
第三方面，本公开实施例还提出一种电子设备，包括：处理器和存储器；所述处理器通过调用所述存储器存储的程序或指令，用于执行如第一方面所述微内核架构的设备驱动方法的步骤。
第四方面，本公开实施例还提出一种非暂态计算机可读存储介质，用于存储程序或指令，所述程序或指令使计算机执行如第一方面所述微内核架构的设备驱动方法的步骤。
可见，本公开的至少一个实施例中，采用驱动主线程和设备子线程的主从线程架构模式，在操作系统启动时，仅启动驱动主线程，而不启动设备子线程，减少设备子线程对系统资源的消耗；并且，驱动主线程和设备子线程通过RPC方式提供设备驱动服务，具体地，当驱动主线程接收到的第一RPC消息为设备启动请求后，驱动主线程再启动设备节点的设备子线程，进而由设备子线程确定接收到的第二RPC消息为设备操作请求后，对设备节点进行对应的操作，解决目前的微内核架构中，应用无法直接调用设备驱动的问题。
附图说明
为了更清楚地说明本公开实施例的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
图1是宏内核的架构示意图和微内核架构示意图；
图2是本公开实施例提供的一种微内核架构的设备驱动方法的流程图；
图3是本公开实施例提供的一种启动设备子线程的流程图；
图4是本公开实施例提供的另一种启动设备子线程的流程图；
图5是本公开实施例提供的一种微内核架构的设备驱动方法的交互图；
图6是本公开实施例提供的一种微内核架构的设备驱动装置的示例性框图；
图7是本公开实施例提供的一种电子设备的示例性框图。
具体实施方式
为了能够更清楚地理解本公开的上述目的、特征和优点，下面结合附图和实施例对本公开作进一步的详细说明。可以理解的是，所描述的实施例是本公开的一部分实施例，而不是全部的实施例。此处所描述的具体实施例仅仅用于解释本公开，而非对本公开的限定。基于所描述的本公开的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本公开保护的范围。
需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。
微内核是一种能够提供必要服务的操作系统内核，其中，必要服务包括但不限于任务、线程、交互进程通信(IPC，Inter-Process Communication)以及内存管理等。所有服务(包括设备驱动)运行于用户态，而处理这些服务同处理其他的任何一个程序一样，因为每个服务只是在自己的地址空间运行。
为了解决现有技术存在的至少一个问题，本公开的至少一个实施例提供了一种微内核架构的设备驱动方法、装置、电子设备和非暂态计算机可读存储介质，采用主从线程的架构模式对设备驱动加载方式及设备驱动对外提供服务的应用程序编程接口(Application Programming Interface，API)进行了详细的设计。其中，设备驱动加载包括：设备节点的RPC服务注册和设备节点的注册。设备驱动对外提供的服务包括：设备启动请求(open)、设备关闭请求(close)和设备操作请求，其中，设备操作请求包括但不限于：写请求(write)、读请求(read)、输入/输出请求(ioctl)等。
本公开的至少一个实施例中，采用驱动主线程和设备子线程的主从线程架构模式，在操作系统启动时，仅启动驱动主线程，而不启动设备子线程，减少设备子线程对系统资源的消耗；并且，驱动主线程和设备子线程通过RPC方式提供设备驱动服务，具体地，当驱动主线程接收到的第一RPC消息为设备启动请求后，驱动主线程再启动设备节点的设备子线程，进而由设备子线程确定接收到的第二RPC消息为设备操作请求后，对设备节点进行对应的操作，解决目前的微内核架构中，应用无法直接调用设备驱动的问题。
图2是本公开实施例提供的一种微内核架构的设备驱动方法的流程图。采用微内核架构的操作系统在启动时，例如操作系统接收到启动指令，启动指令例如用户按压开机按键而产生的指令，操作系统响应启动指令仅启动驱动主线程，而不启动设备子线程， 减少设备子线程对操作系统软硬件资源的消耗。在一些实施例中，设备子线程可以有多个，每个设备子线程与一个设备节点对应，不论设备子线程有多少个，操作系统在启动时，均不启动这些设备子线程。
在操作系统启动驱动主线程后，在步骤201中，驱动主线程通过RPC服务接收第一RPC消息。
其中，RPC(Remote Procedure Call，远程过程调用)服务是微服务架构中不同进程之间进行交互的一种方式，虽然微服务架构中应用无法直接调用设备驱动，但是应用进程可以通过RPC方式向设备驱动所处的进程发送第一RPC消息，这样，驱动主线程可以通过RPC方式提供设备驱动服务。
在步骤202中，驱动主线程确定第一RPC消息为设备启动请求后，启动对应的设备节点的设备子线程。
驱动主线程通过RPC方式提供的设备驱动服务包括设备启动请求(open)，这样，应用进程可以通过RPC方式向驱动主线程发送设备启动请求，在该设备启动请求中携带待启动的设备节点的信息。
驱动主线程确定接收到的第一RPC消息为设备启动请求后，可以基于该设备启动请求中携带的设备节点的信息，确定该设备启动请求对应的设备节点，进而启动对应的设备节点的设备子线程。
可见，设备子线程的启动是由驱动主线程来控制，当有应用进程需要使用某个设备节点时，驱动主线程才会启动该设备节点的设备子线程，这样，可以减少设备节点未被使用时，设备子线程对操作系统软硬件资源的消耗。
在步骤203中，设备子线程在启动后通过RPC服务接收第二RPC消息。
设备子线程在启动后，可以通过RPC方式提供设备驱动服务，设备驱动服务例如为设备操作请求，设备操作请求包括但不限于：写请求(write)、读请求(read)、输入/输出请求(ioctl)等。这样，应用进程可以通过RPC方式向设备子线程发送设备操作请求。
需要说明的是，设备子线程在启动后所接收的第二RPC消息均是针对该设备子线程所对应的设备节点。
在步骤204中，设备子线程确定第二RPC消息为设备操作请求后，对设备节点进行对应的设备操作。
若设备操作请求为写请求，则设备子线程对设备节点进行写操作；若设备操作请求为读请求，则设备子线程对设备节点进行写操作；若设备操作请求为输入/输出请求，则设备子线程对设备节点进行输入/输出操作。
可见，实施例中采用驱动主线程和设备子线程的主从线程架构模式，在操作系统启动时，仅启动驱动主线程，而不启动设备子线程，减少设备子线程对系统资源的消耗； 并且，驱动主线程和设备子线程通过RPC方式提供设备驱动服务，具体地，当驱动主线程接收到的第一RPC消息为设备启动请求后，驱动主线程再启动设备节点的设备子线程，进而由设备子线程确定接收到的第二RPC消息为设备操作请求后，对设备节点进行对应的操作，解决目前的微内核架构中，应用无法直接调用设备驱动的问题。
在一些实施例中，驱动主线程通过RPC服务接收第一RPC消息之前，驱动主线程需要先注册并启动主线程RPC服务，进而才能通过主线程RPC服务接收第一RPC消息。
驱动主线程在注册并启动主线程RPC服务后，可以注册一个或多个设备节点的RPC服务并注册每个设备节点。在一些实施例中，驱动主线程可以扫描驱动列表，得到一个或多个设备类型以及每个设备类型对应的设备节点，进而注册每个设备节点的RPC服务并注册每个设备节点。这样，任一设备子线程在启动后可以通过该设备子线程对应的设备节点的RPC服务接收第二RPC消息。
在一些实施例中，驱动主线程确定第一RPC消息为设备启动请求后，有多种方式启动对应的设备节点的设备子线程。
例如，图3为本公开实施例提供的一种启动设备子线程的流程图。在步骤301中，驱动主线程接收设备启动请求。该步骤中，驱动主线程等待接收第一RPC消息，当驱动主线程确定接收的第一RPC消息为设备启动请求后，执行步骤302。
在步骤302中，驱动主线程打开设备启动请求对应的设备节点。该步骤中，驱动主线程可以基于设备启动请求中携带的设备节点的信息(例如设备节点的名称)，确定对应的设备节点，进而打开该设备节点。在一些实施例中，驱动主线程通过将ops(操作方法)指针指向ops结构体的成员：open，也即ops->open，以打开该设备节点。
在步骤303中，驱动主线程在打开设备节点后，启动设备节点的设备子线程。由于设备子线程是在设备节点打开后才启动，因此，设备子线程在启动后可以直接通过RPC服务接收第二RPC消息。
又例如，图4为本公开实施例提供的另一种启动设备子线程的流程图。步骤401与图3中的步骤301相同，不再赘述。
在步骤402中，驱动主线程调用操作系统提供的创建线程API()，以创建设备启动请求对应的设备节点的设备子线程。本实施例中，与图3实施例不同的是，驱动主线程在接收到设备启动请求后，不是先打开设备节点再启动设备节点的设备子线程，而是直接调用创建线程API来创建设备节点的设备子线程。
在步骤403中，设备子线程在启动后打开对应的设备节点。与图3实施例不同的是，设备节点并非由驱动主线程打开，而是由设备子线程打开。具体地，设备子线通过将ops(操作方法)指针指向ops结构体的成员：open，也即ops->open，以打开该设备节点。
设备子线程在打开设备节点后，且确定第二RPC消息为设备操作请求后，对设备节点进行对应的设备操作。
在一些实施例中，驱动主线程注册每个设备节点时，可以向第一VFS(Virtual File System，虚拟文件系统)库注册每个设备节点，其中，第一VFS库为驱动主线程所在进程的VFS库；或者，驱动主线程可以向PM(Pass Manager，路径管理)进程注册每个设备节点。
在一些实施例中，应用进程在第二VFS库中查找待启动的设备节点是否已注册，其中，第二VFS库为应用进程的VFS库；若未注册，则应用进程查找主线程RPC服务。在一些实施例中，主线程RPC服务由驱动主线程在PM进程中注册并启动，因此，应用进程在PM进程中查找主线程RPC服务，PM进程将查询结果反馈给应用进程。
应用进程查找到主线程RPC服务后，可以基于主线程RPC服务向驱动主线程发送设备启动请求。
在一些实施例中，应用进程查找主线程RPC服务的同时还可以查找待启动的设备节点的RPC服务。在一些实施例中，主线程RPC服务由驱动主线程在PM进程中注册并启动，设备节点的RPC服务也由驱动主线程在PM进程中注册，因此，应用进程在PM进程中查找主线程RPC服务以及待启动的设备节点的RPC服务，PM进程将查询结果反馈给应用进程。
应用进程接收到驱动主线程反馈的设备启动结果后，若设备启动结果为成功，则应用进程基于待启动的设备节点的RPC服务向设备子线程发送设备操作请求。
在一些实施例中，驱动主线程通过RPC方式提供的设备驱动服务包括设备关闭请求(open)，这样，应用进程可以通过RPC方式向驱动主线程发送设备关闭请求，在该设备启动请求中携带待关闭的设备节点的信息或者设备启动结果，以便驱动主线程可以确定设备关闭请求对应的设备节点。
驱动主线程确定第一RPC消息为设备关闭请求后，结束对应的设备节点的设备子线程。驱动主线程在结束对应的设备节点的设备子线程后，关闭设备节点。在一些实施例中，驱动主线程通过将ops(操作方法)指针指向ops结构体的成员：close，也即ops->close，以关闭该设备节点。
结合以上各方法实施例的描述，图5是本公开实施例提供的一种微内核架构的设备驱动方法的交互图，需要说明的是，图5仅为本公开的一些实施例，而非全部实施例。
在图5中，为了便于描述，仅示出一个设备子线程，本领域技术人员可以理解，设备子线程可以有多个，且交互流程类似。
在图5中，采用微内核架构的操作系统在启动时，例如操作系统接收到启动指令，启动指令例如用户按压开机按键而产生的指令，操作系统响应启动指令仅启动驱动主线程，而不启动设备子线程，减少设备子线程对操作系统软硬件资源的消耗。
在图5中，驱动主线程启动后，在PM进程中注册并启动主线程RPC服务，并且在PM进程中注册设备节点的RPC服务以及注册设备节点。在完成以上注册工作后，驱动 主线程可以等待RPC消息。
在图5中，应用进程在第二VFS库中查找待启动的设备节点是否已注册，其中，第二VFS库为应用进程的VFS库；若未注册，则应用进程在PM进程中进行RPC服务查询，RPC服务查询包括查找主线程RPC服务和待启动的设备节点的RPC服务。
PM进程将查询结果反馈给应用进程，其中，查询结果中包括：主线程RPC服务信息和待启动的设备节点的服务信息。应用进程在获取到查询结果后，基于主线程RPC服务向驱动主线程发送设备启动请求，设备启动请求中携带设备节点的信息(例如设备节点的名称)。
在图5中，驱动主线程接收到设备启动请求后，基于设备启动请求中携带的设备节点的信息，确定对应的设备节点，进而通过将ops(操作方法)指针指向ops结构体的成员：open，也即ops->open，以打开该设备节点。
驱动主线程在打开设备节点后，启动设备节点的设备子线程，并将设备启动结果反馈给应用进程。由于设备子线程是在设备节点打开后才启动，因此，设备子线程在启动后可以直接等待RPC消息。
在图5中，应用进程接收到驱动主线程反馈的设备启动结果后，若设备启动结果为成功，则应用进程基于待启动的设备节点的RPC服务向设备子线程发送设备操作请求。
设备子线程接收到设备操作请求后，对设备节点进行对应的设备操作。若设备操作请求为写请求，则设备子线程对设备节点进行写操作；若设备操作请求为读请求，则设备子线程对设备节点进行写操作；若设备操作请求为输入/输出请求，则设备子线程对设备节点进行输入/输出操作。
在图5中，应用进程可以向驱动主线程发送设备关闭请求，在该设备启动请求中携带待关闭的设备节点的信息或者设备启动结果，以便驱动主线程可以确定设备关闭请求对应的设备节点。
驱动主线程接收到设备关闭请求后，结束对应的设备节点的设备子线程。驱动主线程在结束对应的设备节点的设备子线程后，通过将ops(操作方法)指针指向ops结构体的成员：close，也即ops->close，以关闭该设备节点。
可见，图5所示的微内核架构的设备驱动方法的交互流程，采用驱动主线程和设备子线程的主从线程架构模式，在操作系统启动时，仅启动驱动主线程，而不启动设备子线程，减少设备子线程对系统资源的消耗；并且，驱动主线程和设备子线程通过RPC方式提供设备驱动服务，具体地，当驱动主线程接收到设备启动请求后，驱动主线程再启动设备节点的设备子线程，进而由设备子线程基于接收到的设备操作请求，对设备节点进行对应的操作，解决目前的微内核架构中，应用无法直接调用设备驱动的问题。
图6是本公开实施例提供的一种微内核架构的设备驱动装置，该设备驱动装置包括：驱动主线程61和设备子线程62。采用微内核架构的操作系统响应启动指令而启动驱动 主线程61，且不启动设备子线程62。该设备驱动装置可以包括多个设备子线程62，每个设备子线程62与一个设备节点对应。
驱动主线程61，用于通过RPC服务接收第一RPC消息，并确定第一RPC消息为设备启动请求后，启动对应的设备节点的设备子线程62。
设备子线程62，用于在启动后通过RPC服务接收第二RPC消息，并确定第二RPC消息为设备操作请求后，对设备节点进行对应的设备操作。
在一些实施例中，驱动主线程61，还用于通过RPC服务接收第一RPC消息之前，注册并启动主线程RPC服务，并在启动主线程RPC服务后，注册一个或多个设备节点的RPC服务并将注册每个设备节点。
在一些实施例中，驱动主线程61确定第一RPC消息为设备启动请求后，启动对应的设备节点的设备子线程62，具体包括：确定第一RPC消息为设备启动请求后，打开设备启动请求对应的设备节点；在打开设备节点后，启动设备节点的设备子线程62。
在一些实施例中，驱动主线程61确定第一RPC消息为设备启动请求后，启动对应的设备节点的设备子线程62，具体包括：确定第一RPC消息为设备启动请求后，调用操作系统提供的创建线程API，以创建设备启动请求对应的设备节点的设备子线程62。
在一些实施例中，设备子线程62在启动后打开对应的设备节点，在打开设备节点后，且确定第二RPC消息为设备操作请求后，对设备节点进行对应的设备操作。
在一些实施例中，驱动主线程61注册一个或多个设备节点的RPC服务并将注册每个设备节点，具体包括：扫描驱动列表，得到一个或多个设备类型以及每个设备类型对应的设备节点；注册每个设备节点的RPC服务；并在注册每个设备节点的RPC服务后注册每个设备节点。
在一些实施例中，驱动主线程61注册每个设备节点，具体包括：向第一VFS库注册每个设备节点，其中，第一VFS库为驱动主线程所在进程的VFS库；或，向PM进程注册每个设备节点。
在一些实施例中，设备启动请求由应用进程通过如下方式发送：
应用进程在第二VFS库中查找待启动的设备节点是否已注册，其中，第二VFS库为应用进程的VFS库；若未注册，则应用进程查找主线程RPC服务；应用进程基于主线程RPC服务向驱动主线程发送设备启动请求。
在一些实施例中，应用进程查找主线程RPC服务的同时还查找待启动的设备节点的RPC服务。应用进程接收到驱动主线程反馈的设备启动结果后，若设备启动结果为成功，则应用进程基于待启动的设备节点的RPC服务向设备子线程发送设备操作请求。
在一些实施例中，驱动主线程61在PM进程中注册并启动主线程RPC服务。应用进程在PM进程中查找主线程RPC服务。
在一些实施例中，驱动主线程61还用于确定第一RPC消息为设备关闭请求后，结 束对应的设备节点的设备子线程62；驱动主线程61在结束对应的设备节点的设备子线程62后，关闭设备节点。
以上各装置实施例的细节可参考各方法实例的细节，为避免重复，不再赘述。
图7是本公开实施例提供的一种电子设备的结构示意图。如图7所示，电子设备包括：至少一个处理器71、至少一个存储器72和至少一个通信接口73。电子设备中的各个组件通过总线系统74耦合在一起。通信接口73，用于与外部设备之间的信息传输。可理解地，总线系统74用于实现这些组件之间的连接通信。总线系统74除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但为了清楚说明起见，在图7中将各种总线都标为总线系统74。
可以理解，本实施例中的存储器72可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。
在一些实施方式中，存储器72存储了如下的元素，可执行单元或者数据结构，或者他们的子集，或者他们的扩展集：操作系统和应用程序。
其中，操作系统，包含各种系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础任务以及处理基于硬件的任务。应用程序，包含各种应用程序，例如媒体播放器(Media Player)、浏览器(Browser)等，用于实现各种应用任务。实现本公开实施例提供的微内核架构的设备驱动方法的程序可以包含在应用程序或操作系统中。
在本公开实施例中，处理器71通过调用存储器72存储的程序或指令，具体的，可以是应用程序中存储的程序或指令，处理器71用于执行本公开实施例提供的微内核架构的设备驱动方法各实施例的步骤。
本公开实施例提供的微内核架构的设备驱动方法可以应用于处理器71中，或者由处理器71实现。处理器71可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器71中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器71可以是通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
本公开实施例提供的微内核架构的设备驱动方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件单元组合执行完成。软件单元可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器72，处理器71读取存储器72中的信息，结合其硬件完成方法的步骤。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列 的动作组合，但是本领域技术人员能够理解，本公开实施例并不受所描述的动作顺序的限制，因为依据本公开实施例，某些步骤可以采用其他顺序或者同时进行。另外，本领域技术人员能够理解，说明书中所描述的实施例均属于可选实施例。
本公开实施例还提出一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行如微内核架构的设备驱动方法各实施例的步骤，为避免重复描述，在此不再赘述。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本公开的范围之内并且形成不同的实施例。
本领域的技术人员能够理解，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
虽然结合附图描述了本公开的实施方式，但是本领域技术人员可以在不脱离本公开的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。

Claims (12)

  1. 一种微内核架构的设备驱动方法，其中，操作系统响应启动指令而启动驱动主线程，且不启动设备子线程，所述方法包括：
    所述驱动主线程通过RPC服务接收第一RPC消息；
    所述驱动主线程确定所述第一RPC消息为设备启动请求后，启动对应的设备节点的设备子线程；
    所述设备子线程在启动后通过RPC服务接收第二RPC消息；
    所述设备子线程确定所述第二RPC消息为设备操作请求后，对所述设备节点进行对应的设备操作。
  2. 根据权利要求1所述的方法，其中，所述驱动主线程通过RPC服务接收第一RPC消息之前，所述方法还包括：
    所述驱动主线程注册并启动主线程RPC服务；
    所述驱动主线程在启动所述主线程RPC服务后，注册一个或多个设备节点的RPC服务并将注册每个所述设备节点。
  3. 根据权利要求1所述的方法，其中，所述驱动主线程确定所述第一RPC消息为设备启动请求后，启动对应的设备节点的设备子线程，包括：
    所述驱动主线程确定所述第一RPC消息为设备启动请求后，打开所述设备启动请求对应的设备节点；
    所述驱动主线程在打开所述设备节点后，启动所述设备节点的设备子线程。
  4. 根据权利要求1所述的方法，其中，所述驱动主线程确定所述第一RPC消息为设备启动请求后，启动对应的设备节点的设备子线程，包括：
    所述驱动主线程确定所述第一RPC消息为设备启动请求后，调用所述操作系统提供的创建线程API，以创建所述设备启动请求对应的设备节点的设备子线程。
  5. 根据权利要求4所述的方法，其中，所述方法还包括：
    所述设备子线程在启动后打开对应的设备节点；
    所述设备子线程在打开所述设备节点后，且确定所述第二RPC消息为设备操作请求后，对所述设备节点进行对应的设备操作。
  6. 根据权利要求2所述的方法，其中，所述注册一个或多个设备节点的RPC服务并将注册每个所述设备节点，包括：
    所述驱动主线程扫描驱动列表，得到一个或多个设备类型以及每个所述设备类型对应的设备节点；
    所述驱动主线程注册每个所述设备节点的RPC服务；
    所述驱动主线程在注册每个所述设备节点的RPC服务后注册每个所述设备节点。
  7. 根据权利要求2所述的方法，其中，所述设备启动请求由应用进程通过如下方式发送：
    所述应用进程在第二VFS库中查找待启动的设备节点是否已注册，其中，所述第二VFS库为所述应用进程的VFS库；若未注册，则所述应用进程查找主线程RPC服务；
    所述应用进程基于所述主线程RPC服务向所述驱动主线程发送所述设备启动请求。
  8. 根据权利要求7所述的方法，其中，所述应用进程查找主线程RPC服务的同时还查找所述待启动的设备节点的RPC服务；
    所述应用进程接收到所述驱动主线程反馈的设备启动结果后，若所述设备启动结果为成功，则所述应用进程基于所述待启动的设备节点的RPC服务向所述设备子线程发送所述设备操作请求。
  9. 根据权利要求1所述的方法，其中，所述方法还包括：
    所述驱动主线程确定所述第一RPC消息为设备关闭请求后，结束对应的设备节点的设备子线程；
    所述驱动主线程在结束对应的设备节点的设备子线程后，关闭所述设备节点。
  10. 一种微内核架构的设备驱动装置，其中，所述装置包括：驱动主线程和设备子线程；操作系统响应启动指令而启动所述驱动主线程，且不启动所述设备子线程；
    所述驱动主线程，用于通过RPC服务接收第一RPC消息，并确定所述第一RPC消息为设备启动请求后，启动对应的设备节点的设备子线程；
    所述设备子线程，用于在启动后通过RPC服务接收第二RPC消息，并确定所述第二RPC消息为设备操作请求后，对所述设备节点进行对应的设备操作。
  11. 一种电子设备，包括：处理器和存储器；
    所述处理器通过调用所述存储器存储的程序或指令，用于执行如权利要求1至9任一项所述方法的步骤。
  12. 一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行如权利要求1至9任一项所述方法的步骤。
PCT/CN2022/102981 2021-06-30 2022-06-30 微内核架构的设备驱动方法、装置、电子设备和存储介质 Ceased WO2023274376A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110734252.7 2021-06-30
CN202110734252.7A CN115562731B (zh) 2021-06-30 2021-06-30 微内核架构的设备驱动方法、装置、电子设备和存储介质

Publications (1)

Publication Number Publication Date
WO2023274376A1 true WO2023274376A1 (zh) 2023-01-05

Family

ID=84692553

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/102981 Ceased WO2023274376A1 (zh) 2021-06-30 2022-06-30 微内核架构的设备驱动方法、装置、电子设备和存储介质

Country Status (2)

Country Link
CN (1) CN115562731B (zh)
WO (1) WO2023274376A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5675795A (en) * 1993-04-26 1997-10-07 International Business Machines Corporation Boot architecture for microkernel-based systems
CN101980170A (zh) * 2010-10-20 2011-02-23 北京星网锐捷网络技术有限公司 一种微内核系统中软件模块的通信方法、系统及装置
CN107368342A (zh) * 2017-08-10 2017-11-21 北京元心科技有限公司 驱动硬件扩展模块的方法、装置及终端设备
CN109117253A (zh) * 2017-06-26 2019-01-01 阿里巴巴集团控股有限公司 一种微内核调度的方法和装置
CN110764825A (zh) * 2018-07-27 2020-02-07 华为技术有限公司 一种开机方法及终端设备

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7404193B2 (en) * 2003-09-03 2008-07-22 Intel Corporation Method, system, and program for accessing device driver functions
JP2005258897A (ja) * 2004-03-12 2005-09-22 Fuji Xerox Co Ltd 周辺機器制御プログラム、プログラム制御装置およびプログラム制御方法
CN104360889B (zh) * 2014-12-08 2017-11-10 中科创达软件股份有限公司 一种驱动程序加载方法及装置
US11086800B2 (en) * 2019-06-01 2021-08-10 Apple Inc. Execution space agnostic device drivers

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5675795A (en) * 1993-04-26 1997-10-07 International Business Machines Corporation Boot architecture for microkernel-based systems
CN101980170A (zh) * 2010-10-20 2011-02-23 北京星网锐捷网络技术有限公司 一种微内核系统中软件模块的通信方法、系统及装置
CN109117253A (zh) * 2017-06-26 2019-01-01 阿里巴巴集团控股有限公司 一种微内核调度的方法和装置
CN107368342A (zh) * 2017-08-10 2017-11-21 北京元心科技有限公司 驱动硬件扩展模块的方法、装置及终端设备
CN110764825A (zh) * 2018-07-27 2020-02-07 华为技术有限公司 一种开机方法及终端设备

Also Published As

Publication number Publication date
CN115562731B (zh) 2026-03-27
CN115562731A (zh) 2023-01-03

Similar Documents

Publication Publication Date Title
CN110413386B (zh) 多进程处理方法、装置、终端设备及计算机可读存储介质
CN108062252B (zh) 一种信息交互方法、对象管理方法及装置和系统
CN108023808B (zh) 应用程序中的消息分发方法及装置
WO2020151306A1 (zh) 一种容器自适应伸缩方法、服务器及存储介质
WO2019019380A1 (zh) 混合app的页面导航方法、装置、终端和存储介质
WO2022199283A1 (zh) 用于确定调用栈栈帧的对象的方法、装置、设备和介质
TWI783034B (zh) 實現驅動的系統及方法
CN111258565A (zh) 小程序的生成方法、系统、服务器及存储介质
CN116414377A (zh) web网页与原生应用的交互方法、电子设备及存储介质
WO2022199284A1 (zh) 调用栈回溯方法、装置、设备和介质
US20110066836A1 (en) Operating system booting method, computer, and computer program product
WO2023044877A1 (zh) 一种渲染任务处理方法、装置、电子设备及存储介质
CN114205848B (zh) 虚拟wifi上网方法、装置、计算机设备和存储介质
WO2023274376A1 (zh) 微内核架构的设备驱动方法、装置、电子设备和存储介质
US20240126600A1 (en) Service process invoking method and related apparatus
CN111475435A (zh) 一种存储介质共享方法、装置及电子设备和存储介质
WO2024093409A1 (zh) 服务组件的调用方法、装置、计算机设备以及存储介质
CN113841125B (zh) 将持久存储器作为易失性存储器的运行时分配和利用
CN116149803A (zh) 数据库的事务处理方法、装置、电子设备及存储介质
US8321606B2 (en) Systems and methods for managing memory using multi-state buffer representations
WO2023123458A1 (zh) 进程通信方法及装置
CN115617496B (zh) 用户模式与内核模式通信的方法、装置、电子设备和介质
US12299506B1 (en) Configuring a message card
JP2002297402A (ja) デジタル機器、タスク管理方法及びそのプログラム
JP4149619B2 (ja) 優先度変換システム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22832188

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22832188

Country of ref document: EP

Kind code of ref document: A1