Microkernel operating system access method, system, device, storage medium and product

Abstract

Embodiments of the present application provide a microkernel operating system access method, system, device, storage medium and product. The system includes a device management module and a plurality of sub-device management modules, each sub-device management module is used for managing a sub-driver service process created based on a type of driver, each sub-driver service process includes a plurality of logical devices and at least one driver, and one driver is used for serving at least one logical device of the same device type; the method includes: receiving an application program APP sending an operation request containing a device handle to a sub-driver service process corresponding to a sub-driver service process index through inter-process communication; the sub-driver service process index and the device handle are obtained by the APP from the device management module; the logical device corresponding to the device handle is queried through the sub-driver service process, and a logical device driver interface is called to execute an operation corresponding to the operation request. The present application can improve communication efficiency, reduce maintenance cost and reduce the risk of system failure.

Description

Technical Field

[0001] This application belongs to the technical field of operating system access, and in particular relates to a microkernel operating system access method, system, device, storage medium and product. Background Technology

[0002] Operating systems, as a core technology, have always been a difficult area for domestic technology companies to manage. Currently, many operating system development projects have emerged in China, but most of these operating systems are based on monolithic kernel systems. Therefore, most publicly available driver management frameworks are also based on monolithic kernel operating systems, and there are very few driver frameworks for microkernel operating systems.

[0003] Existing technologies for device driver management in microkernel operating systems primarily employ two approaches. The first approach creates a separate service process for each driver, with interactions between drivers achieved through inter-process communication (IPC). This approach suffers from low communication efficiency due to the large number of drivers and frequent inter-driver calls, thus impacting overall driver performance. The second approach integrates all drivers into a single service process, avoiding frequent IPC issues. However, this high integration leads to higher maintenance costs, and a failure in any single driver can cause the entire system to malfunction, posing a significant risk.

[0004] Therefore, existing technologies suffer from low communication efficiency, high maintenance costs, and a high risk of system malfunction. Summary of the Invention

[0005] This application provides a method, system, device, storage medium, and program product for accessing a microkernel operating system, which can improve communication efficiency, reduce maintenance costs, and reduce the risk of system malfunction.

[0006] In a first aspect, embodiments of this application provide a method for accessing a microkernel operating system. The microkernel operating system includes a device management module and multiple sub-device management modules. Each sub-device management module manages sub-driver service processes created based on a driver type. Each sub-driver service process includes multiple logical devices and at least one driver. A driver serves at least one logical device of the same device type. The method includes: The application (APP) receives an operation request sent by inter-process communication to the sub-driver service process corresponding to the sub-driver service process index. The operation request includes a device handle. The sub-driver service process index and device handle are obtained by the APP from the device management module. The sub-driver service process queries the logical device corresponding to the device handle and calls the logical device driver interface to execute the operation corresponding to the operation request.

[0007] In some embodiments, the device management module includes a device table, which includes device information. The device information includes device identifiers of all logical devices in the microkernel operating system, device handles of the logical devices corresponding to the device identifiers, and sub-driver service process indexes of the sub-driver service processes to which the logical devices belong. Before receiving an operation request sent by the application APP to the sub-driver service process corresponding to the sub-driver service process index through inter-process communication, the method may further include: The device management module receives device query requests sent by the APP. The device query request includes the target device identifier. The device management module iterates through the device table to query the device handle corresponding to the target device identifier and the index of the sub-driver service process corresponding to the target device. The device management module sends the sub-driver service process index and device handle to the APP.

[0008] In some embodiments, the device management module includes a device table and a driver table; before receiving an operation request sent by the application (APP) to the sub-driver service process corresponding to the sub-driver service process index via inter-process communication, the method may further include performing the following steps through the device management module: After compiling and linking the device's hardware resource information and the driver's driver information, the hardware resource information is stored in the device table, and the driver information is stored in the driver table. Traverse the device table and driver table to match devices and drivers; If the device and driver are successfully matched, the binding of the matched device and driver is performed, and the information of the bound device and driver is mounted onto the device driver bus.

[0009] In some embodiments, after traversing the device table and driver table to match devices and drivers, the method may further include: If the device and driver match successfully, the logical device corresponding to the device is generated; This is used for logical devices to register with the sub-device management module via function calls, and for the sub-device management module to allocate device handles to the logical devices; The sub-device management module sends a device information update request to the device management module through inter-process communication. The device information update request includes device information, which includes the sub-driver service process index, logical device identifier, and device handle of the sub-driver service process served by the sub-device management module. The equipment management module adds equipment information to the equipment table.

[0010] In some embodiments, the method may further include: The device management module receives device management requests sent by the sub-device management module and creates a thread for device information requests. Device management requests include device information for adding or deleting devices. The device management module stores the device information of newly added devices in the device table of the device management module based on the device management request, or deletes device information from the device table.

[0011] In some embodiments, the logical device driver interface includes a unified access driver interface and a dedicated access driver interface, with the dedicated access driver interface being identical for the same device type; invoking the logical device driver interface to execute the operation corresponding to the operation request may include: Based on the operation type of the operation request, the unified access driver interface of the logical device is invoked to execute the operation corresponding to the operation request; Alternatively, the operation corresponding to the operation request can be executed by calling the dedicated access driver interface of the logical device.

[0012] In some embodiments, driver types are classified according to the complexity of the driver and the degree of coupling between devices. Driver types include simple driver types, load driver types, and strongly coupled device types.

[0013] Secondly, embodiments of this application provide a microkernel operating system, which includes a device management module and multiple sub-device management modules. Each sub-device management module is used to manage sub-driver service processes created based on a driver type. Each sub-driver service process includes multiple logical devices and at least one driver. A driver is used to serve at least one logical device of the same device type. The device management module is used to receive operation requests sent by the application (APP) to the sub-driver service process corresponding to the sub-driver service process index via inter-process communication. The operation request includes a device handle; wherein, the sub-driver service process index and the device handle are obtained by the APP from the device management module. The sub-driver service process in the sub-device management module queries the logical device corresponding to the device handle and calls the logical device driver interface to execute the operation corresponding to the operation request.

[0014] Thirdly, embodiments of this application provide a device including a microkernel operating system. The device includes: a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the access method of the microkernel operating system as described in the first aspect.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the access method of the microkernel operating system as described in the first aspect.

[0016] Fifthly, embodiments of this application provide a computer program product, including a computer program, which, when executed, implements the access method of a microkernel operating system as described in the first aspect.

[0017] The microkernel operating system access method, apparatus, device, and computer storage medium of this application embodiment significantly reduce communication redundancy overhead and improve the communication efficiency of driver interaction by setting each sub-device management module to centrally manage sub-driver service processes of the same driver type. Each sub-driver service process integrates multiple logical devices and corresponding drivers, and a driver serves at least one logical device of the same device type, realizing driver splitting and isolation by type. When a driver in a certain sub-driver service process fails, it only affects the service of the logical device of that type, without causing the entire system to crash, reducing the risk of the system not being able to be used normally and improving the stability of system operation. After the APP obtains the sub-driver service process index and device handle from the device management module, it sends an operation request containing the device handle to the target sub-driver service process through inter-process communication. Then, the sub-driver service process queries the logical device corresponding to the handle and calls the driver interface to perform the operation, realizing the APP's accurate access to the device and further ensuring the efficiency of driver interaction. By adopting a hierarchical management architecture of device management module and multiple sub-device management modules, the main driver management module is responsible for the management of sub-driver services, reducing the complexity and risk level of driver management services. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the structure of the microkernel operating system access system provided in the embodiments of this application; Figure 2 This is a flowchart of the microkernel operating system access method provided in the embodiments of this application; Figure 3 This is a flowchart illustrating the operation of the device management module provided in an embodiment of this application; Figure 4 This is a flowchart illustrating the operation of the sub-device management module provided in this application embodiment; Figure 5 This is a flowchart of the driver and device registration provided in the embodiments of this application; Figure 6 This is a flowchart of the device access process provided in the embodiments of this application; Figure 7 This is a schematic diagram of the structure of the microkernel operating system access device provided in the embodiments of this application; Figure 8 This is a schematic diagram of the structure of the terminal device provided in the embodiments of this application. Detailed Implementation

[0020] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0021] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0022] It should be noted that the acquisition, storage, use, and processing of data in this application embodiment all comply with the relevant provisions of national laws and regulations.

[0023] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0024] Operating systems, as a core technology, have always been a challenging area for domestic technology companies. Currently, many operating system development projects have emerged in China, but most are based on monolithic kernel systems. Therefore, publicly available driver management frameworks are also mostly implemented based on monolithic kernel operating systems, with very few driver frameworks specifically for microkernel operating systems. Existing technologies for device driver management on microkernel operating systems mainly employ two approaches. The first approach creates an independent service process for each driver, with interactions between drivers achieved through inter-process communication (IPC). This method strictly adheres to microkernel principles, ensuring the independence of system modules. However, due to the large number of drivers and frequent inter-driver calls, communication efficiency is low, thus affecting overall driver performance. Furthermore, multiple independent driver processes increase the complexity of device management. The second approach integrates all drivers into a single service process, avoiding frequent IPC issues and significantly reducing driver management costs. However, while the first approach ensures the independence of driver services, the need for inter-process communication between drivers leads to low communication efficiency, especially when driver calls are frequent, impacting system performance. Moreover, as the number of drivers increases, the complexity and maintenance difficulty of device management also rise. The second approach integrates all drivers into a single service. While this reduces the overhead of inter-process communication, the high degree of integration leads to higher maintenance costs. If a driver malfunctions, the entire system may fail to operate properly, posing a significant risk.

[0025] To address the problems of existing technologies, this application provides a microkernel operating system access method, system, device, storage medium, and product. By employing a hierarchical management architecture with a device management module and multiple sub-device management modules, the responsibilities of different types of drivers are clearly defined. Specific sub-driver service processes can be independently maintained, updated, or debugged, reducing maintenance complexity, coupling risks, and costs. Each sub-device management module centrally manages sub-driver service processes of the same driver type, significantly reducing communication redundancy overhead and improving the communication efficiency of driver interaction. Each sub-driver service process integrates multiple logical devices and corresponding drivers, and a driver serves at least one logical device of the same device type, achieving driver type-based isolation. When a driver within a sub-driver service process malfunctions, it only affects the service of that type of logical device, preventing system paralysis, reducing the risk of system malfunction, and improving system stability. After obtaining the sub-driver service process index and device handle from the device management module, the APP sends an operation request containing the device handle to the target sub-driver service process via inter-process communication. The sub-driver service process then queries the logical device corresponding to the handle and calls the driver interface to execute the operation, enabling precise access to the device by the APP and further ensuring driver interaction efficiency.

[0026] The microkernel operating system access system provided in the embodiments of this application will be introduced first below.

[0027] Figure 1 A schematic diagram of the structure of a microkernel operating system access system provided in one embodiment of this application is shown. Figure 1 As shown, the microkernel operating system access system includes a main device management module and multiple sub-device management modules. The main device management module manages the multiple sub-device management modules. The main device management module maintains a device list, which includes information about the logical devices in the multiple sub-device management modules.

[0028] Each sub-device management module manages a driver of one driver type. Each sub-device management module includes at least one logical device. A sub-device management module manages multiple logical devices within that sub-device management module.

[0029] Driver type can be categorized based on driver complexity or the degree of coupling between devices. For example, based on driver complexity, driver types can be divided into simple driver types and complex driver types. Simple driver types include... Figure 1 In the context of serial and GPIO devices, complex driver types include... Figure 1 Network devices, USB HCD devices, and Graphics devices are examples. Another example is classifying drivers based on the degree of coupling between devices; driver types can be categorized into strongly coupled types, such as... Figure 1 i2c_bus and i2c devices.

[0030] like Figure 1 As shown, the APP communicates with the process of the main device management module through inter-process communication (IPC), and the APP also communicates with the sub-driver service process corresponding to the sub-device management module through IPC.

[0031] The APP first initiates a device query request to the main device management module through inter-process communication. The main device management module obtains the sub-driver service process index and device handle corresponding to the target device from the device table and returns them. The APP then locates the corresponding sub-device management module through the index and sends an operation request containing the device handle to the sub-driver service process it manages. The sub-driver service process queries the logical device corresponding to the handle, calls the driver interface (ops) of the logical device to execute the operation, and completes the APP's access to the device.

[0032] In this application, the driver interface of the logic device may include a unified driver interface and a dedicated driver interface.

[0033] The following is combined with Figure 2This application provides a detailed description of the microkernel operating system access method.

[0034] Figure 2 This is a schematic diagram of a microkernel operating system access method provided in an embodiment of this application.

[0035] Figure 2 The access method shown is based on Figure 1 The microkernel operating system access system completed, such as Figure 1 As shown, the system includes a device management module and multiple sub-device management modules. Each sub-device management module is used to manage sub-driver service processes created based on a driver type. Each sub-driver service process includes multiple logical devices and at least one driver. A driver is used to serve at least one logical device of the same device type.

[0036] like Figure 2 As shown, the method may include S101 and S102.

[0037] S101, receive the operation request sent by the application APP to the sub-driver service process corresponding to the sub-driver service process index through inter-process communication. The operation request includes the device handle; wherein, the sub-driver service process index and the device handle are obtained by the APP from the device management module.

[0038] As mentioned earlier, before an app can access a device, it can send a query request to the central management device to obtain the device handle of the device to be accessed, as well as the sub-driver service process index of the sub-management module where the device to be accessed is located.

[0039] After the APP obtains the sub-driver service process index and device handle, it sends an operation request to the sub-driver service process corresponding to the sub-driver service process index via inter-process communication. The operation request includes the device handle, which is used to query the device based on the device handle.

[0040] S102, the sub-driver service process queries the logical device corresponding to the device handle and calls the logical device driver interface to execute the operation corresponding to the operation request.

[0041] After receiving an operation request, the sub-driver service process queries the logical device based on the device handle in the operation request. Once the logical device corresponding to the device handle is found, the logical device driver interface is invoked to execute the operation corresponding to the operation request.

[0042] This application's embodiments employ a hierarchical management architecture consisting of a device management module and multiple sub-device management modules. This architecture clearly defines the responsibilities of different types of drivers, allowing for independent maintenance, updates, or debugging of specific sub-driver service processes, reducing maintenance complexity, coupling risks, and costs. Each sub-device management module centrally manages sub-driver service processes of the same driver type, significantly reducing communication redundancy overhead and improving the communication efficiency of driver interaction. Each sub-driver service process integrates multiple logical devices and their corresponding drivers, with each driver serving at least one logical device of the same device type. This achieves driver type-based separation and isolation, ensuring that if a driver within a sub-driver service process malfunctions, it only affects the service of that type of logical device, preventing system-wide failure and reducing the risk of system inoperability, thus improving system stability. After obtaining the sub-driver service process index and device handle from the device management module, the APP sends an operation request containing the device handle to the target sub-driver service process via inter-process communication. The sub-driver service process then queries the logical device corresponding to the handle and calls the driver interface to execute the operation, enabling the APP to accurately access the device and further ensuring driver interaction efficiency.

[0043] In some embodiments, the device management module includes a device table, which includes device information. The device information includes device identifiers of all logical devices in the microkernel operating system, device handles of the logical devices corresponding to the device identifiers, and sub-driver service process indexes of the sub-driver service processes to which the logical devices belong. Before receiving an operation request sent by the application APP to the sub-driver service process corresponding to the sub-driver service process index through inter-process communication, the method may further include: The device management module receives device query requests sent by the APP, and the device query request includes the target device identifier.

[0044] When an app needs to access a specific target device, it first constructs a device query request containing the target device identifier, and then sends the request to the main device management module through an inter-process communication mechanism. The main device management module listens for and receives device query requests from the app in real time, parses the received device query requests, and extracts the target device identifier.

[0045] In some embodiments, the target device identifier may include the device name, device ID, and device type code.

[0046] This embodiment of the application receives device query requests from the APP carrying the target device identifier through the device management module, which clarifies the APP's device access requirements and anchors the target direction for subsequent accurate query of device information; at the same time, by receiving requests through a unified entry point, it avoids the request dispersion and management chaos caused by the APP directly interacting with each sub-driver service process, and strengthens the uniformity and standardization of the device query process.

[0047] The device management module iterates through the device table to query the device handle corresponding to the target device identifier and the index of the sub-driver service process corresponding to the target device.

[0048] After parsing the target device identifier in the device query request sent by the APP, the device management module retrieves its pre-maintained device table. According to the preset traversal rules, the device management module compares the identifier information of each device in the device table with the target device identifier to accurately locate the matching device entry. From the device entry, it extracts the unique device handle corresponding to the target device and the index of the sub-driver service process to which the device belongs, thus completing the accurate query of device information and the extraction of key data.

[0049] In some embodiments, the device table may include the identifier of each device, the corresponding device handle, and the index of the sub-driver service process to which it belongs.

[0050] This application embodiment achieves rapid retrieval and location of device information by using the device management module to traverse the device table it maintains and accurately match the device handle and sub-driver service process index corresponding to the target device identifier. At the same time, relying on the centralized storage characteristics of the device table, the uniqueness of the query results is ensured, providing a reliable basis for subsequent targeted access to the sub-driver service process by the APP.

[0051] The device management module sends the sub-driver service process index and device handle to the APP.

[0052] After completing the query of the target device information and extracting the corresponding sub-driver service process index and device handle, the device management module forwards the sub-driver service process index and device handle to the application that initiated the query request, the APP, through the inter-process communication channel between the module and the APP. After receiving the response data packet, the APP can accurately extract the sub-driver service process index and device handle from it.

[0053] In some embodiments, the response data packet includes a field identifier of the sub-driver service process index, a numerical value of the device handle, or its encoding.

[0054] In this embodiment, the device management module feeds back the sub-driver service process index and device handle to the APP, directly providing the APP with the core location information for accessing the target device. This reduces the complexity of the APP's connection with the sub-driver service process and improves the efficiency of the device access process.

[0055] The device management module in this embodiment stores key information of all logical devices in a centralized device table. The APP can quickly obtain the location information of the target device through a device query request. At the same time, the unified maintenance of the device table ensures the consistency and accuracy of device information, providing a reliable source of location information for communication between the APP and the sub-driver service process.

[0056] In some embodiments, the device management module includes a device table and a driver table; before receiving an operation request sent by the application (APP) to the sub-driver service process corresponding to the sub-driver service process index via inter-process communication, the method may further include performing the following steps through the device management module: After the hardware resource information of the device and the driver information of the driver are compiled and linked, the hardware resource information is stored in the device table and the driver information is stored in the driver table.

[0057] After the hardware resource information of the device and the driver information of the driver are compiled and linked, the preset device table and driver table are first initialized. The hardware resource information of the device is obtained through hardware scanning or configuration file parsing. According to the field specifications of the device table, this information is filled into the corresponding entries in the device table one by one to ensure that the hardware parameters of each device are complete and searchable. The valid driver information after the driver is compiled and linked is extracted. According to the storage rules of the driver table, the driver information is classified and entered into the driver table to complete the structured storage of driver data.

[0058] In some embodiments, hardware resource information may include device physical address, interrupt number, register parameters, device model identifier, and hardware characteristic parameters.

[0059] In some embodiments, driver information may include driver name, version number, list of supported device types, driver interface function pointers, and driver dependency library information.

[0060] This application embodiment achieves categorized storage and structured management of device and driver information by storing device hardware resource information in a device table and driver information in a driver table. This avoids management chaos caused by mixed device and driver information, establishes a clear and searchable data foundation for subsequent device and driver matching, ensures the system can quickly locate devices and corresponding driver resources, and facilitates subsequent independent maintenance and updates of device or driver information.

[0061] Traverse the device table and driver table to match devices and drivers.

[0062] In some embodiments, traversing the device table and driver table to match devices and drivers may include: The system retrieves the stored device table and driver table, and reads each device entry from the device table one by one according to the preset traversal rules, extracting the core identification information of the device. For each device information entry, it traverses the driver entries in the driver table, comparing each supported device type or device ID with the identification information of the current device to verify the compatibility between the device hardware characteristics and the driver adaptation requirements. If a driver entry and a device entry meet the matching conditions, the device and driver are marked as a successfully matched combination. This process continues until all device entries in the device table have completed the matching verification, and finally, all compatible device and driver combinations are selected.

[0063] The core identification information of a device may include the device ID and the device type.

[0064] In some embodiments, matching criteria may include the device ID being within the driver compatibility range and the device type being consistent with the driver support type.

[0065] This application embodiment traverses the device table and driver table, matching devices and drivers. By comparing the device identifier with the range of devices supported by the driver, it can accurately filter out suitable device and driver combinations. This process solves the device and driver compatibility problem, avoiding invalid driver loading or situations where no matching driver exists for a device, thus providing the prerequisite for normal device driving. At the same time, the traversal matching method ensures that all devices in the system can be checked one by one, improving the comprehensiveness and accuracy of device driver matching.

[0066] If the device and driver are successfully matched, the binding of the matched device and driver is performed, and the information of the bound device and driver is mounted onto the device driver bus.

[0067] Once the device and driver are successfully matched and verified, the preset binding interface is called to establish an association mapping between the hardware resource information of the device in the device table and the interface function of the corresponding driver in the driver table, generating binding relationship data. The device driver bus mounting process is initiated, and the binding relationship data is encapsulated into mounting node information according to the bus data structure specification. The mounting node information is added to the bus node list through the device driver bus registration interface, completing the mounting of the binding information. The device and driver association index table of the bus is updated to ensure that the corresponding driver and resource information of the device can be quickly retrieved through the bus.

[0068] In some embodiments, hardware resource information may include device address and interrupt number.

[0069] Interface functions can include initialization functions and read / write functions.

[0070] Binding relationship data may include device handles, driver identifiers, and resource access permissions.

[0071] The mount node information may include device and driver binding ID, device type, driver version, and bus mount path.

[0072] This embodiment of the application performs binding after successful device and driver matching, and attaches the binding information to the device driver bus, completing the association and docking between the device and driver. This enables the driver to access device hardware resources through the bus, realize device driver control and function calls, and ensure that the device can be correctly recognized and used by the system. Unified management of binding information through the device driver bus achieves centralized monitoring of device and driver relationships, facilitating subsequent dynamic management of device drivers. It also ensures the standardization and efficiency of system calls to device drivers, improving the overall utilization efficiency of hardware resources.

[0073] This application embodiment achieves precise matching between device hardware resources and drivers through the classified storage of device tables and driver tables and the device and driver matching and binding mechanism, ensuring that the device can load the corresponding driver; the mounting management of the device driver bus unifies the association between devices and drivers, making it easier for the system to centrally manage device drivers, improving the efficiency and reliability of device driver matching, and laying the foundation for the creation of subsequent logical devices.

[0074] In some embodiments, after traversing the device table and driver table to match devices and drivers, the method may further include: If the device and driver are successfully matched, the logical device corresponding to the device is generated.

[0075] Once the device and driver have completed the matching verification and confirmed successful adaptation, the data structure of the logical device is constructed based on the hardware resource information of the device and the interface function information of the driver; the driver's initialization interface is called to initialize and configure the device hardware, and the initialized hardware state is synchronized to the logical device data structure; an independent memory space is allocated for the logical device, and the creation and initialization of the logical device instance are completed, thus generating the logical device.

[0076] In some embodiments, hardware resource information may include device address, interrupt number, and register configuration.

[0077] In some embodiments, the driver's interface function information may include initialization functions, read / write functions, and control functions.

[0078] In some embodiments, the data structure of a logical device may include a logical device identifier, an associated physical device hardware resource pointer, a bound driver interface function mapping table, and device status parameters.

[0079] This application's embodiments generate corresponding logical devices after successful device and driver matching, abstracting and encapsulating the hardware resources of the physical device and the adapting driver at the software level to form a system-recognizable and schedulable logical operation unit. This design shields the underlying hardware differences of physical devices, allowing upper-layer applications to indirectly control physical devices without needing to concern themselves with hardware details, solely through the logical devices. Simultaneously, the logical devices, as software mappings of the physical devices, provide a unified operational carrier for subsequent registration management, handle allocation, and inter-process communication, laying the foundation for layered device management.

[0080] This is used for logical devices to register with the sub-device management module via function calls, and the sub-device management module to allocate device handles to the logical devices.

[0081] The logical device initiates a registration request by calling the registration interface function provided by the sub-device management module. The request carries information such as the logical device identifier, its driver type, and hardware resource characteristics. After receiving the request, the sub-device management module first verifies the validity of the logical device information. If the verification is successful, the sub-device management module assigns a unique handle to the logical device. The sub-device management module associates this handle with the logical device information and stores it in the local device list, and then returns the handle allocation result to the logical device.

[0082] In some embodiments, verifying the legality of logical device information may include verifying whether the device identifier is duplicated and whether the driver type belongs to the jurisdiction of the module.

[0083] In some examples, hardware categories may include serial devices, USB devices, and storage devices.

[0084] In this embodiment, the logical devices are registered to the sub-device management module via function calls, enabling centralized management of logical devices of the same type. This allows the sub-device management module to manage all logical devices of the same driver type. Simultaneously, the sub-device management module assigns a unique device handle to each logical device. This handle serves as the core identifier of the logical device, providing a precise addressing basis for subsequent APP device location and operation requests. This avoids access errors caused by confused device identifiers, simplifies device retrieval and management processes, and improves the efficiency and accuracy of device access.

[0085] After a device and driver are successfully matched, a logical device is generated and registration, handle allocation, and device table updates are completed, realizing the software abstraction and system-level management of physical devices. The information of the sub-device management module and the device management module are synchronized, ensuring that the device table can include the information of newly added logical devices in real time, so that the APP can query complete device resources. At the same time, the registration and handle allocation of logical devices provide standardized identification for device access, improving the standardization of device management.

[0086] The sub-device management module sends a device information update request to the device management module via inter-process communication. The device information update request includes device information, which includes the sub-driver service process index, logical device identifier, and device handle of the sub-driver service process served by the sub-device management module.

[0087] The sub-device management module first encapsulates the device information to be sent into a data packet according to a preset communication protocol format, calls the system inter-process communication interface, specifies the process identifier or communication channel identifier of the device management module as the receiver, and sends the encapsulated data packet to the corresponding communication channel. After the device management module obtains the data packet by listening to the communication channel, the sub-device management module will also send an acknowledgment request command at the same time to ensure that the device management module successfully receives and parses the data packet.

[0088] In some embodiments, device information may include a sub-driver service process index, a logical device identifier, and a device handle.

[0089] In some embodiments, the data packet may include a data header, data length, checksum, and specific device information field.

[0090] This embodiment of the application achieves synchronous flow of device information within a hierarchical management architecture by having the sub-device management module send a device information update request, containing the sub-driver service process index, logical device identifier, and device handle, to the device management module via inter-process communication. This ensures that the device management module, as the system-level device information hub, can obtain the latest device registration information in real time, guaranteeing the integrity and timeliness of the device table data. Furthermore, the standardized information transmission format prevents the loss or corruption of device information during transmission, providing reliable data support for subsequent APP queries of device information and targeted access to sub-driver service processes.

[0091] The equipment management module adds equipment information to the equipment table.

[0092] The device management module first parses the received device information update request data packet, extracting key data such as the sub-driver service process index, logical device identifier, and device handle. It then checks if an entry with the same logical device identifier exists in the device table. If not, it creates a new device table entry according to the table's preset data structure, filling the extracted key data into the corresponding fields and updating the table's index pointers to maintain the table's integrity. A validation mechanism verifies the data consistency of the newly added entry; once confirmed to be correct, the device information is added to the device table.

[0093] In some embodiments, the preset data structure may include a device identifier field, a handle field, and a sub-driver process index field.

[0094] In some embodiments, verifying the data consistency of newly added entries through a verification mechanism may include checking the handle encoding format or the validity of the process index.

[0095] This embodiment adds received device information to the device table through the device management module, completing system-level filing and structured storage of device information. This makes the device table a global information center covering all logical devices, ensuring that the APP can quickly query the complete location information of the target device through the device management module. Simultaneously, centralized storage of device information facilitates unified system supervision, maintenance, and scheduling of devices, avoiding information redundancy or inconsistency caused by decentralized management. This further enhances the collaborative efficiency of the layered architecture of the device management module and sub-device management modules, providing data assurance for improving the overall performance and stability of system device access.

[0096] In some embodiments, the method may further include: The device management module receives device management requests sent by the sub-device management module and creates a thread for device information requests. Device management requests include device information for adding or deleting devices.

[0097] The device management module continuously listens for requests sent from the sub-device management module through a preset inter-process communication listening interface. When a device management request data packet sent by the sub-device management module is detected, the module first reads the data packet through the receiving function of the communication interface, parses out the request type and the attached device information, calls the thread creation interface, creates a device information request thread based on the preset thread processing function, and passes the parsed request parameters to the thread, thus completing the initialization and triggering of the request receiving and processing thread.

[0098] In some embodiments, the request type may include a new device request type or a delete device request type.

[0099] In some embodiments, device information may include a device identifier.

[0100] After receiving a device management request from the sub-device management module, the device management module of this application creates a device information request thread. The operation of adding or deleting devices in the device management request is handled by an independent thread, which improves the system's concurrent response capability. At the same time, threaded processing can isolate and control device management requests, making it easier to allocate independent resources for different requests, reducing the risk of operation conflicts, and ensuring the stability and security of device information change operations.

[0101] The device management module stores the device information of newly added devices in the device table of the device management module based on the device management request, or deletes device information from the device table.

[0102] After parsing the device management request, if it is a request to add a device, the device management module first verifies the validity of the device information. If the verification is successful, a new entry is created according to the data structure of the device table, the information of the new device is filled into the corresponding fields, and the index of the device table is updated to maintain the table structure, thus completing the addition operation.

[0103] If it is a device deletion request, the device table is traversed according to the device identifier in the device deletion request to locate the target entry, the resources associated with the entry are released, the entry is removed from the device table and the storage structure of the table is adjusted, the consistency of the device table data is confirmed through the verification mechanism, and the deletion operation is completed.

[0104] In some embodiments, verifying the legality of device information may include verifying the uniqueness of the device identifier and the validity of the sub-driver process index.

[0105] In some embodiments, the data structure of the device table may include a device identifier, a handle, and a sub-driver process index.

[0106] This application embodiment achieves dynamic updates to the device table by using a device management module to store newly added device information into the device table or delete specified device information from the device table upon request. Adding a device ensures the device table synchronously incorporates information about newly connected devices, guaranteeing the app can access the latest device resources. Deleting a device promptly cleans up outdated device data, preventing invalid information from occupying storage and ensuring the device table always maintains accurate and complete device information. Furthermore, the unified execution of add and delete operations on the device table through the device management module strengthens centralized control over device information, avoids data corruption caused by multiple processes directly manipulating the device table, and maintains the consistency of the device table.

[0107] The device management module in this embodiment of the application processes the device management requests of the APP in a threaded manner, thereby realizing the asynchronous execution of device addition and deletion operations, avoiding the blocking of the main process by request processing, and improving the system's concurrent processing capability; at the same time, through the dynamic updating of the device table, it ensures that the device information can reflect the changes of the system devices in a timely manner, maintains the accuracy and timeliness of the device table, and ensures the flexibility of device management and the stability of the system.

[0108] In some embodiments, the logical device driver interface includes a unified access driver interface and a dedicated access driver interface, with the dedicated access driver interface being identical for the same device type; invoking the logical device driver interface to execute the operation corresponding to the operation request may include: Based on the operation type of the operation request, the unified access driver interface of the logical device is invoked to execute the operation corresponding to the operation request; Alternatively, the operation corresponding to the operation request can be executed by calling the dedicated access driver interface of the logical device.

[0109] The operation type and target logical device identifier in the operation request are parsed. If the operation type is a general device type, the default unified access driver interface of the logical device is called, and the operation parameters are passed into the interface. The interface implements the general operation logic according to the driver bound to the logical device to complete the data interaction or status control.

[0110] If the operation type is device-specific, the dedicated access driver interface corresponding to the logical device is matched, dedicated parameters are passed in, the interface calls the operation logic customized for the device in the driver, executes dedicated instructions or configurations at the hardware level, and finally returns the operation execution result to complete the execution of the operation request.

[0111] This application's embodiments categorize logical device driver interfaces into two types: unified access driver interfaces and dedicated access driver interfaces. Unified access driver interfaces meet general operational needs, while dedicated access driver interfaces adapt to device-specific functions. This ensures both the universality and standardization of device operation while also catering to the personalized needs of different devices, thereby improving the adaptability of the driver interface and the completeness of device functions.

[0112] In some embodiments, driver types are classified according to the complexity of the driver and the degree of coupling between devices. Driver types include simple driver types, load driver types, and strongly coupled device types.

[0113] In some embodiments, a simple driver type may include a serial port or GPIO.

[0114] In some embodiments, the load drive type may include an Ethernet device or a USB device.

[0115] In some embodiments, a strongly coupled device type may include an I2C bus and its connected devices.

[0116] based on Figure 1 The microkernel operating system access system allows the APP to access the central device management module through communication, such as... Figure 3 As shown, the process is as follows: While creating the service for the main device management module (i.e., the process for creating the main device management module), the system waits for communication from this process and checks whether it has received access from a client. This client can be an app or a sub-device management module. If the client's access information is detected, a thread is created to execute the client's access request. This access request can include device management requests and device search requests.

[0117] When the client is an APP, the access request is a device lookup request. It traverses the device table maintained in the main device management module to find the device identifier of the device to be found in the device lookup request, such as the device name. When the main device management module finds the logical device corresponding to the device identifier, it sends the sub-device management module index (which can also be understood as the sub-driver service process index) and the device handle of the logical device to the client through IPC communication.

[0118] When the client is a sub-device management module, the access request is a device management request, and the task of executing this device management request is as follows: The device management request can include adding or deleting a device. Specifically, the task of executing this device management request is to add the device identifier of the device to be added or deleted, as included in the device management request, to the device table maintained by the main device management module, or to delete the device identifier from the device table maintained by the main device management module. In this application, the addition and deletion of devices are handled through the sub-device management module, which initiates the device management request to the main device management module. The APP does not directly participate in the addition and deletion of devices. This achieves two goals: first, it decouples the functions of the processes; second, it avoids giving the APP (i.e., the user) too many management permissions, preventing malicious or accidental deletion of settings drivers by the user, which could lead to system malfunctions.

[0119] In Figure 3 In the process of waiting for client access, the system continues to wait for further communication. After completing one communication between the app and the central device management module, it continues to wait for further communication.

[0120] Figure 4 This is a schematic diagram of the operation method of the sub-device management module provided in the embodiments of this application.

[0121] Figure 4 The operating method shown is based on Figure 1 The microkernel operating system access system completed, such as Figure 1 As shown, in this system, subdev corresponds to the sub-device management module, which is responsible for managing the sub-driver service processes of a specific driver type. It includes multiple logical devices and their corresponding drivers, and works in conjunction with the main device management module (devmgr) to complete device management.

[0122] based on Figure 1The system described above operates as follows: Upon creating a subdevice management module (subdev), it is first registered with the main device management module (devmgr) for easy management. Simultaneously, threads for device initialization and registration are created. Then, an infinite loop is entered, waiting for communication from this process and checking for client access (which can be an application). If client access is detected, the client ID is obtained, a thread is created to execute the client's access request, and upon receiving the device handle from the client, the target device for the corresponding subdevice management module (subdev) is located. Then, the subdevice management module's open, read, write, control, and close interfaces are called to connect to the device driver. If the device has a dedicated operation interface (Priv_ops), it is called first, connecting to the device driver through the dedicated operation interface. After completing the device operation, the operation result is returned to the application via inter-process communication (IPC).

[0123] During the service initialization phase, the thread searches the device table and driver table to complete the matching, binding and registration of devices and drivers, and stores the device information in the subdev_list of the subdevice management module and the device table of the main device management module (devmgr), respectively.

[0124] When a client access request is received, the thread will locate the corresponding device in the subdevice management module based on the input device handle and perform device operations. Specifically, it will call the driver interface of the subdevice management module, connect to the device driver, and return the result to the APP through IPC communication.

[0125] The driver interface can be divided into unified driver interfaces and dedicated driver interfaces. A unified driver interface is as follows: Figure 4 In this context, functions such as open (open the device), read (read data from the device), write (write data to the device), control (control the device), and close (close the device) can be included. Dedicated driver interfaces include... Figure 3 Private driver interface for Chinese devices.

[0126] Figure 5 This is a schematic diagram of the device initialization stage driver and device registration provided in the embodiments of this application.

[0127] Figure 5 The registration process shown is based on Figure 4 It is completed based on the operation method of the sub-device management module, such as... Figure 3 As shown, in this operating method, the subdevice management module needs to complete the matching and binding of devices and drivers, while Figure 4 The process is a prerequisite for this binding process.

[0128] based on Figure 4 The sub-device management module operation method, specifically the driver and device registration process during the device initialization phase, is as follows: During the device initialization phase, the drivers corresponding to devices such as xx_uart, xx_i2c, xx_GPIO, and xx_eth will be connected to the driver and device bus through the driver registration process; at the same time, the information (info) corresponding to these devices will also be associated with the bus through the device registration process.

[0129] After both the driver and the device have completed bus registration, the matching of the device and the driver can be achieved based on the bus: the driver will identify the corresponding device hardware resources through the bus, and the device will also load the matching driver through the bus, thus completing the binding of the device and the driver, providing a foundation for the creation and invocation of logical devices in the subsequent subdevice management module.

[0130] Figure 6 This is a schematic diagram illustrating the interaction process between an APP and a device in a microkernel operating system provided in this application embodiment.

[0131] Figure 6 The interactive flow shown is based on Figure 1 The microkernel operating system access system completed, such as Figure 1 As shown, the system includes a main device management module (Devmgr process) and multiple sub-device management modules (subdev processes). The main device management module maintains a device table to manage information for all sub-devices.

[0132] based on Figure 1 The interaction process between the APP and the device in the system described above is as follows: First, the subdevice management modules, such as subdevice process 1 and subdevice process 2, will send a device registration request to the Devmgr process to synchronize the device information they manage to the device table of the Devmgr process; then, the APP process sends a finddevice request to the Devmgr process to query the information of the target device; after receiving the request, the Devmgr process searches for the corresponding device data in the device table and returns the subdev index and deviceindex to which the device belongs to the APP process.

[0133] After the APP process obtains the subdev / device index, it obtains the corresponding subdev / devicehandle based on the index, and then sends a device operation request to the target subdev process (such as subdev process 1 and subdev process 2). After receiving the request, the subdev process finds the corresponding device it manages, executes the device operation corresponding to the operation request, and completes the APP's access to the device.

[0134] Figure 7 This application provides a microkernel operating device 200. For example... Figure 7 As shown, the microkernel operating device includes a device management module and multiple sub-device management modules. Each sub-device management module is used to manage sub-driver service processes created based on a driver type. Each sub-driver service process includes multiple logical devices and at least one driver. A driver is used to serve at least one logical device of the same device type. The device management module 201 is used to receive operation requests sent by the application APP to the sub-driver service process corresponding to the sub-driver service process index through inter-process communication. The operation request includes a device handle; wherein, the sub-driver service process index and the device handle are obtained by the APP from the device management module 201. The sub-driver service process in the sub-device management module 202 queries the logical device corresponding to the device handle and calls the logical device driver interface to execute the operation corresponding to the operation request.

[0135] This application's embodiments employ a hierarchical management architecture consisting of a device management module and multiple sub-device management modules. Each sub-device management module centrally manages sub-driver service processes of the same driver type, and each sub-driver service process integrates multiple logical devices and their corresponding drivers. This design allows the application (APP) to directly obtain the sub-driver service process index and device handle from the device management module, and then accurately send operation requests containing device handles to the target sub-driver service process via inter-process communication. This solves the problem of excessive process numbers and frequent inter-process communication caused by creating independent service processes for each driver, significantly reducing communication redundancy overhead and significantly improving the communication efficiency of driver interaction. The design of splitting and classifying driver service processes according to driver type clarifies the responsibilities of different types of drivers, allowing for independent maintenance, updates, or debugging of specific sub-driver service processes. This avoids operating within a large process integrating all drivers into a single service process, reducing maintenance complexity and coupling risks, and lowering maintenance costs. With drivers separated and isolated by type in different sub-driver service processes, if a driver within a sub-driver service process fails, only the service of that type of logical device is affected, preventing the entire system from crashing. This reduces the risk of system malfunction and improves system stability.

[0136] In some embodiments, the device may further include: The device query request receiving module is used to receive a device query request sent by the APP through the device management module. The device query request includes the target device identifier. The device query request receiving module is used to traverse the device table through the device management module to query the device handle corresponding to the target device identifier and the sub-driver service process index corresponding to the target device. The query result return module is used to send the sub-driver service process index and the device handle to the APP through the device management module.

[0137] The device management module in this embodiment stores key information of all logical devices in a centralized device table. The APP can quickly obtain the location information of the target device through a device query request, avoiding scattered queries of device information and simplifying the process of the APP accessing the device. At the same time, the unified maintenance of the device table ensures the consistency and accuracy of device information, providing reliable data support for communication between the APP and the sub-driver service process.

[0138] In some embodiments, the device may further include: The resource information storage module is used to store the hardware resource information in the device table and the driver information in the driver table after the hardware resource information of the device and the driver information of the driver are compiled and linked. The device driver matching module is used to traverse the device table and the driver table to match devices and drivers; The device driver binding and mounting module is used to bind the successfully matched device and driver when they are successfully matched, and to mount the information of the bound device and driver onto the device driver bus.

[0139] This application embodiment achieves precise matching between device hardware resources and drivers through the classified storage of device tables and driver tables and the device and driver matching and binding mechanism, ensuring that the device can load the corresponding driver; the mounting management of the device driver bus unifies the association between devices and drivers, making it easier for the system to centrally manage device drivers, improving the efficiency and reliability of device driver matching, and laying the foundation for the creation of subsequent logical devices.

[0140] In some embodiments, the device may further include: A logic device generation module is used to generate a logic device corresponding to the device when the device and driver are successfully matched. The logical device registration handle allocation module is used to enable logical devices to register with the sub-device management module through function calls, and the sub-device management module allocates device handles to the logical devices. The device information update request sending module is used to send a device information update request to the device management module through inter-process communication via the sub-device management module. The device information update request includes device information, which includes the sub-driver service process index, logical device identifier, and device handle of the sub-driver service process served by the sub-device management module. The device information addition module is used by the device management module to add device information to the device table.

[0141] This embodiment adds received device information to the device table through the device management module, completing system-level filing and structured storage of device information. This makes the device table a global information center covering all logical devices, ensuring that the APP can quickly query the complete location information of the target device through the device management module. Simultaneously, centralized storage of device information facilitates unified system supervision, maintenance, and scheduling of devices, avoiding information redundancy or inconsistency caused by decentralized management. This further enhances the collaborative efficiency of the layered architecture of the device management module and sub-device management modules, providing data assurance for improving the overall performance and stability of system device access.

[0142] In some embodiments, the device may further include: The device management request processing thread creation module is used to receive device management requests sent by the sub-device management module through the device management module, and create a thread for the device information request, wherein the device management request includes device information for adding or deleting devices; The device information addition / deletion module is used to store device information of newly added devices into the device table of the device management module, or delete device information from the device table, based on the device management request, through the device management module.

[0143] The device management module in this embodiment of the application processes the device management requests of the APP in a threaded manner, thereby realizing the asynchronous execution of device addition and deletion operations, avoiding the blocking of the main process by request processing, and improving the system's concurrent processing capability; at the same time, through the dynamic updating of the device table, it ensures that the device information can reflect the changes of the system devices in a timely manner, maintains the accuracy and timeliness of the device table, and ensures the flexibility of device management and the stability of the system.

[0144] In some embodiments, the device may further include: The unified access driver interface invocation module is used to invoke the unified access driver interface of the logical device based on the operation type of the operation request, and execute the operation corresponding to the operation request. A dedicated access driver interface invocation module is used to invoke the dedicated access driver interface of the logical device to execute the operation corresponding to the operation request.

[0145] This application's embodiments categorize logical device driver interfaces into two types: unified access driver interfaces and dedicated access driver interfaces. Unified access driver interfaces meet general operational needs, while dedicated access driver interfaces adapt to device-specific functions. This ensures both the universality and standardization of device operation while also catering to the personalized needs of different devices, thereby improving the adaptability of the driver interface and the completeness of device functions.

[0146] Figure 8 A schematic diagram of the hardware structure of the terminal device provided in an embodiment of this application is shown.

[0147] The terminal device may include a processor 301 and a memory 302 storing computer program instructions.

[0148] Specifically, the processor 301 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0149] Memory 302 may include mass storage for data or instructions. For example, and not limitingly, memory 302 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 302 may include removable or non-removable (or fixed) media, or memory 302 may be a non-volatile solid-state memory. Memory 302 may be internal or external to the end device.

[0150] In one example, memory 302 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Thus, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods of accessing a microkernel operating system according to this disclosure.

[0151] The processor 301 reads and executes computer program instructions stored in the memory 302 to achieve... Figure 1 The method for accessing the microkernel operating system in the illustrated embodiment.

[0152] In one example, the terminal device may also include a communication interface 303 and a bus 304. Wherein, for example... Figure 7 As shown, the processor 301, memory 302, and communication interface 303 are connected through bus 304 and complete communication with each other.

[0153] The communication interface 303 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0154] Bus 304 includes hardware, software, or both, that couples components of an end device together. For example, and not as a limitation, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 304 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0155] Furthermore, in conjunction with the microkernel operating system access method in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the microkernel operating system access methods in the above embodiments.

[0156] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the microkernel operating system access methods described in the above embodiments.

[0157] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0158] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or text segments used to perform the required tasks. Programs or text segments can be stored on machine-readable media or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable media" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Text segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0159] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0160] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0161] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for accessing a microkernel operating system, characterized in that, The microkernel operating system includes a device management module and multiple sub-device management modules. Each sub-device management module manages sub-driver service processes created based on a driver type. Each sub-driver service process includes multiple logical devices and at least one driver. One driver serves at least one logical device of the same device type. The method includes: The device management module includes a device table and a driver table; After the hardware resource information of the device and the driver information of the driver are compiled and linked, the hardware resource information is stored in the device table and the driver information is stored in the driver table. Traverse the device table and the driver table to match devices and drivers; If the device and driver are successfully matched, a logical device corresponding to the device is generated; Logical devices register with the sub-device management module via function calls, and the sub-device management module assigns device handles to the logical devices. The sub-device management module sends a device information update request to the device management module through inter-process communication. The device information update request includes device information, which includes the sub-driver service process index, logical device identifier, and device handle of the sub-driver service process served by the sub-device management module. The equipment management module adds equipment information to the equipment table; If the device and driver are successfully matched, the binding of the matched device and driver is performed, and the information of the bound device and driver is mounted onto the device driver bus; The application (APP) receives an operation request sent by inter-process communication to the sub-driver service process corresponding to the sub-driver service process index. The operation request includes a device handle. The sub-driver service process index and the device handle are obtained by the APP from the device management module. The sub-driver service process queries the logical device corresponding to the device handle and calls the logical device driver interface to execute the operation corresponding to the operation request.

2. The method according to claim 1, characterized in that, The device management module includes a device table, which includes device information. The device information includes device identifiers of all logical devices in the microkernel operating system, device handles of the logical devices corresponding to the device identifiers, and sub-driver service process indexes of the sub-driver service processes to which the logical devices belong. Before the operation request sent by the receiving application (APP) to the sub-driver service process corresponding to the sub-driver service process index via inter-process communication, the method further includes: The device management module receives a device query request sent by the APP, and the device query request includes the target device identifier. The device management module traverses the device table to query the device handle corresponding to the target device identifier and the sub-driver service process index corresponding to the target device. The device management module sends the sub-driver service process index and the device handle to the APP.

3. The method according to claim 1, characterized in that, The method further includes: The device management module receives device management requests sent by the sub-management module and creates a thread for the device management request. The device management request includes device information for adding or deleting devices. The device management module can store the device information of newly added devices in the device table of the device management module based on the device management request, or delete the device information of devices from the device table.

4. The method according to claim 1, characterized in that, The logical device driver interface includes a unified access driver interface and a dedicated access driver interface. The dedicated access driver interface is the same for the same device type. The operation corresponding to the operation request, which is executed by calling the logical device driver interface, includes: Based on the operation type of the operation request, the unified access driver interface of the logical device is invoked to execute the operation corresponding to the operation request; Alternatively, the operation corresponding to the operation request can be executed by calling the dedicated access driver interface of the logical device.

5. The method according to any one of claims 1 to 4, characterized in that, The drive types are classified according to the complexity of the drive and the degree of coupling between devices. The drive types include simple drive type, load drive type and strongly coupled device type.

6. A microkernel operating system, characterized in that, The microkernel operating system is used to implement the microkernel operating system access method as described in any one of claims 1 to 5. The microkernel operating system includes a device management module and multiple sub-device management modules. Each sub-device management module is used to manage a sub-driver service process created based on a driver type. Each sub-driver service process includes multiple logical devices and at least one driver. A driver is used to serve at least one logical device of the same device type. The application (APP) receives an operation request sent by inter-process communication to the sub-driver service process corresponding to the sub-driver service process index. The operation request includes a device handle. The sub-driver service process index and the device handle are obtained by the APP from the device management module. The sub-driver service process queries the logical device corresponding to the device handle and calls the logical device driver interface to execute the operation corresponding to the operation request.

7. A device comprising a microkernel operating system, characterized in that, The device includes: a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the microkernel operating system access method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the microkernel operating system access method as described in any one of claims 1 to 5.

9. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method for accessing a microkernel operating system as described in any one of claims 1 to 5.

Images