Method and system for reusing host machine driving function during operation of library operating system

Abstract

The invention relates to a method and system for reusing a host machine drive function during operation of a library operating system, and belongs to the field of operating systems, the method comprises the following steps: receiving drive use commands, and finding out a target equipment drive use command from the drive use commands; decomposing the target equipment drive use command to obtain an information transmission command and shared memory data; writing the shared memory data into a shared memory according to the information transmission command; reading the shared memory data, and recombining the information transmission command and the shared memory data to obtain a recombined target equipment drive use command; and transmitting the recombined target equipment drive use command to a host machine to call a drive function of the host machine. Under the condition that the code increment of the library operating system is very small, calling can be carried out in the library operating system without modifying a driving program, the expansion of the micro library pool of the library operating system is realized, and the possibility of expanding the ecology of the library operating system is increased.

Description

Technical Field

[0001] This application relates to the field of operating systems, and in particular to a method and system for reusing host machine driver functions at the runtime of a library operating system. Background Technology

[0002] With the rapid development of cloud computing and virtualization technologies, applications are placing increasingly higher demands on system performance and security. Traditional general-purpose operating systems must maintain numerous functional layers to support various resources and application scenarios, resulting in bloated systems that cannot fully utilize hardware performance. Against this backdrop, lightweight and specialized library operating systems offer an important way to improve application performance.

[0003] Library operating systems modularize operating system functionality, allowing developers to select the minimum necessary set of components to build a custom system image based on application requirements. This "customization" approach not only significantly reduces system overhead but also provides better performance optimization opportunities through customization. However, library operating systems face serious ecosystem challenges in practical applications. On the one hand, developing new libraries requires developers to possess both application domain knowledge and system implementation experience, resulting in excessively high development costs. On the other hand, existing libraries are often too specialized, making them difficult to reuse in different scenarios. The rapid evolution of hardware and application requirements further exacerbates this challenge, necessitating continuous updates and maintenance of the library ecosystem. While building compatibility layers provides a rapid solution for expanding the library ecosystem, this approach introduces a large amount of generic code, contradicting the lightweight design philosophy of library operating systems.

[0004] Currently, the practical application of library operating systems in industry is relatively limited. Theoretically, to achieve the most ideal performance, it is necessary to select the most suitable combination of micro-libraries from the micro-library pool based on the characteristics and needs of the application domain, minimizing unnecessary code. This requires a very large micro-library pool and a very rich resource abstraction ecosystem to support it. There are two main methods for adding micro-libraries: one is to develop them specifically according to the needs of the specific scenario and the target library operating system architecture, rewriting the module work from scratch; the other method is to design and add a compatibility layer, which maps the existing implementation of the library operating system to the interfaces of popular operating systems, enabling software, hardware, and functional micro-libraries adapted to popular operating systems to run.

[0005] For the first approach, implementing micro-libraries for the operating system is difficult. Since operating system libraries typically need to be customized for specific applications or services, a significant amount of specialized work is required to analyze the application's requirements, customize and design the micro-library based on those requirements, and then integrate it with the operating system. Therefore, expanding micro-libraries requires developers to be sufficiently familiar with both the application and the operating system, making the design and expansion of micro-libraries inherently difficult. On the other hand, because micro-library designs are often customized and lack cross-scenario versatility, it means that a micro-library customized for one application is difficult to directly apply to other scenarios, thus limiting its application scope.

[0006] The second approach, building a compatibility layer, provides an interface similar to popular operating systems, becoming a way to rapidly expand library operating system micro-libraries. For example, by supporting the Linux ABI (Linux Application Binary Interface), a binary compatibility layer can be provided for regular executables, achieving binary compatibility between the library operating system and Linux applications. The existence of this binary compatibility layer provides more possibilities for Linux applications to run on the library operating system. However, for the binary compatibility layer to function effectively, the library operating system needs to provide a large number of system call interfaces while adhering to the Linux ABI as much as possible. On the one hand, implementing these system call interfaces is a huge workload for developers; on the other hand, incorporating all implemented system call interfaces as part of a general layer into the final image organization would make the image overly complex, thus losing the security and performance advantages brought by specialization.

[0007] In summary, while library operating systems have clear theoretical advantages, practical applications still face challenges in implementing micro-libraries and expanding their ecosystem. Building a compatibility layer can broaden the application scope of library operating systems in the short term, but in the long run, developing a native ecosystem and providing a larger pool of micro-libraries are essential to truly realize the potential of library operating systems. Summary of the Invention

[0008] Therefore, it is necessary to provide a method and system for reusing host machine driver functions at the runtime of the library operating system to address the above technical problems. This method can call the host machine driver module with very small code increments in the library operating system, so that the driver can be used in the library operating system without modification.

[0009] In a first aspect, embodiments of this application provide a method for reusing host machine driver functionality at library operating system runtime, including: Receive driver usage commands, and find the target device driver usage command from the driver usage commands; The target device driver is decomposed using commands to obtain information transmission commands and shared memory data. According to the information transmission command, the shared memory data is written into the shared memory; Read the shared memory data, reassemble the information transmission command and the shared memory data to obtain the reassembled target device driver usage command; The recombined target device driver is passed to the host machine using a command to invoke the host machine's driver functions.

[0010] In one embodiment, the method for identifying the target device driver usage command from the driver usage commands includes: Obtain the target device information list and the first and second parameters of the driver command; Compare the first parameter with the parameters in the target device information list; When a parameter matching the first parameter is found in the target device information list, the driver usage command is classified as a target device driver usage command.

[0011] In one embodiment, the method for obtaining the target device information list includes: Receive target device information input from the target device; Obtain the path name and file descriptor of the target device driver from the target device information; Store the path name of the target device driver and the file descriptor of the target device driver in the target device information list.

[0012] In one embodiment, the method of reassembling the target device driver using commands includes: The list of uncertain parameters in the target device driver usage command is decomposed into shared memory data; The non-shared memory data in the target device driver usage command is decomposed into a unified information transmission command.

[0013] In one embodiment, the method of writing the shared memory data into the shared memory includes: Obtain the starting address and length of the shared memory data in the information transmission command; Based on the shared memory data start address and the shared memory data start address length, the shared memory data is written into the corresponding location in the shared memory according to the set interaction format.

[0014] In one embodiment, the method for reading the shared memory data includes: Obtain the starting address and length of the shared memory data in the information transmission command; Based on the starting address and length of the shared memory data, the data is read from the corresponding location in the shared memory.

[0015] In one embodiment, the method for decomposing and recombining the information transmission command and the shared memory data includes: The shared memory data is parsed according to the set interaction format. The parsed shared memory data is then reassembled with the information transmission command.

[0016] In a first aspect, embodiments of this application provide a system for reusing host machine driver functions at library operating system runtime, including: The wrapper layer module is used to identify and classify all driver usage commands in the library operating system, and to find the target device driver usage commands. The decomposition module is used to receive commands from the target device driver and decompose them into information transmission commands and shared memory data. The information transfer module is used for information transfer between the library operating system and the host machine; The reassembly module is used to receive information transmission commands and shared memory data and reassemble them into reassembly target device driver usage commands, and then transmit the reassembly target device driver usage commands to the host machine to invoke the host machine driver functions.

[0017] In one embodiment, the packaging layer module includes: The determination submodule is used to determine whether the driver command is a target device driver command; The first submodule is used to pass the target device driver usage commands to the reassembly module; The second submodule is used to pass commands from non-target device drivers to non-target micro-libraries.

[0018] In one embodiment, the information transmission module includes: The transfer submodule is used to synchronize information between the library operating system and the host machine; The shared submodule provides an interactive format for shared memory data to enable the sharing of shared memory data.

[0019] Compared to existing technologies, the method for reusing host machine driver functions at runtime in this application's library operating system takes a runtime approach. It receives driver usage commands, identifies target device driver usage commands from these commands, and uses a specific interaction format to decompose and reassemble these commands. This reassembled command can then be passed to the host machine, transferring the target device driver usage requirements from the application to the host machine. The host machine then provides the corresponding services through its comprehensive and abundant driver resources. While this method increases the time overhead of exiting the virtual machine, it enables the mobilization of numerous complex and large-scale driver modules on the host machine with minimal changes to the library operating system code.

[0020] This application presents a system that reuses host machine driver functionality at runtime within the library operating system. It encapsulates all device driver command interfaces into wrapper layer modules to construct an interaction window between the application and the target device driver on the host machine. It establishes decomposition, information transmission, and reassembly modules to standardize the interaction format, transmitting target device driver commands to the host machine. This enables the target application to use micro-libraries (i.e., target device drivers) not implemented in the library operating system. This system can be used in the library operating system without modifying the target device driver, increasing the potential for ecological expansion of the library operating system's micro-libraries.

[0021] The wrapper layer module and reorganization module of the system that reuses the host machine driver function at runtime in this application library operating system have the characteristics of being modular, detachable, and customizable according to specific needs. They can be regarded as a kind of micro-library, which further improves the possibility of ecological expansion of the library operating system micro-library.

[0022] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0023] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic diagram of the method for reusing host machine driver functions during library operating system runtime provided in the embodiments of this application.

[0024] Figure 2 This is a schematic flowchart of a method for finding target device driver usage commands from the driver usage commands provided in an embodiment of this application.

[0025] Figure 3 This is a schematic flowchart of a method for obtaining a list of target device information provided in an embodiment of this application.

[0026] Figure 4 This is a schematic diagram of the method for obtaining the return value of the target driving command provided in the embodiments of this application.

[0027] Figure 5 This is a schematic flowchart of a method for reorganizing the target device driver's commands into information transmission commands and shared memory data, provided in an embodiment of this application.

[0028] Figure 6 This is a schematic flowchart of a method for reading shared memory data provided in an embodiment of this application.

[0029] Figure 7 This is a schematic flowchart of the method for reorganizing the information transmission command and the shared memory data provided in the embodiments of this application.

[0030] Figure 8 This is a schematic diagram of the information transmission command structure provided in the embodiments of this application.

[0031] Figure 9 This is a system architecture block diagram of the library operating system runtime reusing the host machine driver function provided in the embodiments of this application.

[0032] Figure 10 This is a block diagram of the packaging layer module structure provided in the embodiments of this application.

[0033] Figure 11 This is a structural block diagram of the information transmission module provided in the embodiments of this application.

[0034] Figure 12 This is a schematic diagram illustrating the method and system for reusing host machine driver functions during the runtime of the test program through the operating system of this application library, and the results of executing the call directly on Linux.

[0035] In the diagram, 1 is the system that reuses the host machine driver function during library operating system runtime, 10 is the wrapper layer module, 110 is the judgment submodule, 120 is the first submodule, 130 is the second submodule, 20 is the decomposition module, 30 is the information transmission module, 310 is the transmission submodule, 320 is the sharing submodule, and 40 is the reassembly module. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0037] Obviously, the accompanying drawings described below are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar scenarios based on these drawings without any inventive effort. Furthermore, it is understood that although the efforts made in this development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, any changes to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0038] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0039] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following objects are in an "or" relationship. The terms "first," "second," and "third" used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0040] A first aspect of the present invention provides a method for reusing host machine driver functionality at runtime in a library operating system, such as... Figure 1 As shown, it includes: S1. Receive driver usage commands and find the target device driver usage commands from the driver usage commands.

[0041] For example, if an application has two driver usage commands: `open( / dev / chardev, ORDWR)` and `open( / dev / tty01, ORDWR)`, where `chardev` is the target device and `tty01` is not, then only the `open( / dev / chardev, ORDWR)` command targeting `chardev` will be processed further.

[0042] S2. Decompose the target device driver commands to obtain information transfer commands and shared memory data.

[0043] For example, in the driver command `open( / dev / chardev, ORDWR)`, the number and size of the parameters are fixed, so only the parameters need to be placed in the message passing command. However, in the write command `write(fd, "helloworld", sizeof("helloworld"))`, the position of the parameter "helloworld" represents the content to be written, and the size of this parameter is uncertain. In this invention, it is considered separately and placed in shared memory after the message passing command, and the starting address information of the shared memory is stored as a supplementary parameter in the message passing command.

[0044] S3. Write the shared memory data to the shared memory according to the information transmission command.

[0045] S4. Read the shared memory data, reassemble the information transmission command and the shared memory data to obtain the command to use the reassembled target device driver.

[0046] For example, a common message passing command structure can be set on both the Guest and Host ends, and the characteristics of union can be used to put multiple different system call parameter structures in the same memory. The optype can be used to distinguish which parameter is currently valid, thereby saving memory and unifying the passing structure.

[0047] S5. Pass the command to the host machine to reassemble the target device driver, so as to invoke the driver function of the host machine.

[0048] Specifically, the reconfiguration of the target device driver uses a command passed to the host machine's driver module. After the target driver module receives and correctly executes the command, it provides the correct target driver command return value, writes the target driver command return value to a specified location in shared memory or to a specified parameter in the information transfer command, and passes the information transfer command to the library operating system. The library operating system reads the target driver command return value from the specified location in shared memory or to the specified parameter in the information transfer command, and writes the target driver command return value to the return value location of the application driver's command.

[0049] In virtualization, the host machine refers to the physical computer or server running virtualization software (such as VMware, VirtualBox, Docker, etc.). In a virtualization environment, the host machine provides hardware resources (such as CPU, memory, disk, network, drivers, etc.) for the virtual machines (guest machines). The virtual machine is a simulated computer running on the host machine; it has its own operating system and applications, but all operations are performed on the resources provided by the host machine.

[0050] This application presents a method for reusing host machine driver functionality at runtime within the library's operating system. It considers the runtime process of the library's operating system by receiving driver usage commands, identifying the target device driver usage commands from these commands, and using a specific interaction format to decompose and reassemble these commands. This reassembled command can then be passed to the host machine, transferring the target device driver usage requirements from the application to the host machine. The host machine then leverages its comprehensive and abundant driver resources to provide the corresponding services. While this method increases the time overhead of exiting the virtual machine, it enables the mobilization of numerous complex and large-scale driver modules on the host machine with minimal changes to the library's operating system code.

[0051] Based on the above embodiments, this application provides a detailed explanation of embodiment S1. Specifically, this application involves a method for finding target device driver usage commands from driver usage commands, such as... Figure 2 As shown, it includes the following steps: S11, obtain the target device information list and the first and second parameters of the driver usage command.

[0052] Specifically, the first parameter is either the path name of the device driver or the file descriptor of the device driver.

[0053] It's important to note that in applications, device usage is handled through drivers. Device drivers encapsulate device usage methods into a series of operation interfaces and provide them to the application. In Linux systems, device drivers exist within the file system, so applications calling drivers are similar to file operations. Specifically, the first parameter of a driver command, used for the first time, is the file address, similar to " / dev / chardev". Then, after responding to this open command, the driver in the host registers a file descriptor, which, in this invention, is passed back to the guest. Subsequent calls to the same device driver from the application will use the file descriptor as a distinguishing identifier.

[0054] Specifically, the target device information list refers to a directory list registered in the Guest kernel, which stores the directory address of the target device and its file descriptor in the Host file system.

[0055] In one embodiment of this application, a method for obtaining a list of target device information is described, such as... Figure 3 As shown, it includes the following steps: S111, Receive target device information input by the target device.

[0056] In this embodiment of the application, the target device information (i.e., the target device name, which can be a file descriptor or a file address) is information input by the user. For example, the user registers a set of target devices named " / dev / chardev", " / dev / ttyUSB0", and " / dev / input / event0" in the Guest account.

[0057] S112. Obtain the path name and file descriptor of the target device driver from the target device information. This step is not completed during initialization, but rather when the application first uses the device, i.e., when the device is opened with a command such as open( / dev / chardev, ORDWR), the corresponding file descriptor is generated by the driver management program in the Host and then transferred back to the Guest.

[0058] S113. Store the target device driver's path name and file descriptor in the target device information list. It should be noted that the correspondence between the target device driver's path name and file descriptor will gradually improve as the application runs.

[0059] S12. Compare the first and second parameters with the parameters in the target device information list.

[0060] Specifically, the first parameter of the driver command (i.e., the path name or file descriptor of the device driver) is compared one by one with the parameters in the target device information list (i.e., the path name and file descriptor of the target device driver) until a parameter matching the first parameter is found in the target device information list, or until all parameters in the target device information list have been compared.

[0061] For example, the command to open a device is `open( / dev / chardev, ORDWR)`. In this case, `open` is the operation command, and the parentheses contain its parameter list, with ` / dev / chardev` as the first parameter. Then, the target device information list is searched to determine whether the target device is supported. If the address is included, the target device is supported; otherwise, it is not.

[0062] S13. Determine if there is a parameter in the target device information list that matches the first parameter.

[0063] S14. When there is a parameter in the target device information list that matches the first parameter, classify the driver usage command as a target device driver usage command.

[0064] For example, if the first parameter is the path name of the device driver, the path name of the device driver is compared one by one with the parameters in the target device information list (i.e., the path name of the target device driver and the file descriptor of the target device driver). When the path name of the device driver is found in the parameters of the target device information list, the driver usage command is classified as a target device driver usage command. This corresponds to the first time the device is used, the command `open( / dev / chardev,ORDWR)`, where ` / dev / chardev` exists in the target device list {" / dev / chardev" 0," / dev / ttyUSB0" 0, " / dev / input / event0" 0}, it will be classified as a target device driver usage command, and after use, a corresponding file descriptor, 32 (assuming), is obtained. The target device list is updated to {" / dev / chardev" 32," / dev / ttyUSB0" 0, " / dev / input / event0" 0}.

[0065] For example, if the first parameter is a file descriptor of the device driver, the file descriptor of the device driver is compared one by one with the parameters in the target device information list (i.e., the path name and file descriptor of the target device driver). When the file descriptor of the device driver is found in the parameters of the target device information list, the driver usage command is classified as a target device driver usage command. This case corresponds to the second and subsequent use of the device, such as the command `write(32, "helloworld", sizeof("helloworld"))`. In this case, the first parameter is the file descriptor character, with a value of 32. After comparison in the target device list, it can be determined that it corresponds to the file address ` / dev / chardev`, and it is classified as a target device driver usage command.

[0066] Based on the above embodiments, this application provides a detailed explanation of embodiment S2. Specifically, this application involves a method for decomposing the target device driver using commands, such as... Figure 4 As shown, it includes the following steps: S21, decompose the list of undefined parameters in the target device driver's command into shared memory data.

[0067] For example, in the command `open( / dev / chardev, ORDWR)`, the number and size of the parameters are fixed, so the parameters can be placed directly in the message passing command. However, in the write command `write(fd "helloworld", sizeof("helloworld"))`, the position of "helloworld" represents the content to be written. The characteristic of this parameter is that its size is uncertain. It should be considered separately and placed in shared memory after the message passing command, with the starting address information of the shared memory stored as a supplementary parameter in the message passing command.

[0068] S22 decomposes the non-shared memory data in the target device driver usage command into a unified information transmission command.

[0069] For example, a common message passing command structure can be set on both the Guest and Host ends, and the characteristics of union can be used to put multiple different system call parameter structures in the same memory block. The op_type can be used to distinguish which parameter is currently valid, thereby saving memory and unifying the passing structure.

[0070] Specifically, the information transfer command includes the starting address of the shared memory data, the length of the starting address of the shared memory data, the interface name of the target device driver to use the command, and the file information of the target device driver.

[0071] The shared memory data start address and the shared memory data start address length are used to ensure that shared memory data can be correctly written to and read from the corresponding location in shared memory.

[0072] Based on the above embodiments, this application provides a detailed explanation of embodiment S3. Specifically, this application involves a method for writing shared memory data into shared memory, such as... Figure 5 As shown, it includes the following steps: S31, obtain the starting address and length of the shared memory data in the information transfer command.

[0073] S32, based on the starting address and length of the shared memory data, writes the shared memory data into the corresponding location in the shared memory according to the set interactive format.

[0074] Based on the above embodiments, this application provides a detailed explanation of embodiment S4. Specifically, this application involves a method for reading shared memory data, such as... Figure 6 As shown, it includes the following steps: S411, retrieve the starting address and length of the shared memory data in the information transfer command.

[0075] S412 reads the data from the corresponding location in the shared memory based on the starting address and length of the shared memory data.

[0076] Based on the above embodiments, this application provides a detailed explanation of embodiment S4. Specifically, this application involves a method for reorganizing information transmission commands and shared memory data, such as... Figure 7 As shown, it includes the following steps: S421 parses the shared memory data according to the set interaction format.

[0077] Specifically, it can ensure that the shared memory data read can be correctly reassembled.

[0078] S422 reassembles the parsed shared memory data with the information transfer commands.

[0079] Specifically, both the Guest and Host ends use the same message passing command structure, see [link / reference]. Figure 8The instruction structure (i.e., the information transmission command structure) divides the instruction (i.e. the transmission command) into the following components: instruction name, operation object, and instruction parameters. Among them, the instruction parameters are divided into parameters with fixed length (such as: operation identifier O_RDWR, etc.) and parameters with variable length (such as: the write operation will carry the content to be written, and the length of this parameter will change with the content to be written).

[0080] Specifically, such as Figure 8 As shown, during the process of instructions moving from the Guest to shared memory, the instruction name, operand, and fixed-length parameters are stored in the instruction structure section of shared memory. Variable-length parameters are stored in the parameter storage section of shared memory, and their starting address and length in the parameter storage section are added as new parameters to the instruction structure.

[0081] When instructions are transferred from shared memory to the host, they are parsed and reassembled. First, the instruction structure is parsed to extract information such as the instruction name, operands, fixed-length parameters, the starting address for storing variable-length parameters, and the length of the variable-length parameters. Then, based on the starting address and length of the variable-length parameters, the corresponding content (i.e., the variable-length parameters) is read from the specified location at the parameter storage address. To simplify this process, the read operation is directly integrated into the final instruction.

[0082] For example, consider the instruction `write(fd, "helloworld")`. The instruction name is `write`, the operand is `fd`, and it has only one parameter of variable length. During the process of the instruction moving from the Guest to shared memory, the variable-length parameter is stored in the parameter storage section, immediately following the instruction structure. Its initial position is `sizeof(struct syscall_info)`, which is relative to the shared memory location. Therefore, the final instruction structure will contain the instruction name `write`, the operand `fd`, the starting address of the variable-length parameter storage `sizeof(struct syscall_info)`, and the variable-length parameter length `count`. The parameter storage section stores the content "helloworld". When the instruction moves from shared memory to the Host, the "helloworld" content is reconstructed using the starting address of the variable-length parameter storage `sizeof(struct syscall_info)` and the variable-length parameter length `count` in the instruction structure. The final instruction becomes `write(fd, shm_addr + sizeof(struct syscall_info), count)`, where `shm_addr` is the starting address of the shared memory.

[0083] A second aspect of the present invention provides a system for reusing host machine driver functionality at the runtime of a library operating system, such as... Figure 9 As shown, it includes: The wrapper layer module 10 is used to identify and classify all driver usage commands in the library operating system and find the target device driver usage commands.

[0084] Specifically, the wrapper layer module 10, located in the library operating system, is detachable and can be customized according to specific needs. It can be regarded as a micro-library of the library operating system to improve the possibility of ecological expansion of the library operating system micro-libraries.

[0085] The decomposition module 20 is used to receive the target device driver usage command and decompose it into information transmission command and shared memory data.

[0086] Specifically, located in the library operating system, the decomposition module 20 has the characteristics of being detachable and customizable according to specific needs. It can be regarded as a micro-library of the library operating system to improve the possibility of ecological expansion of the library operating system micro-libraries.

[0087] The information transmission module 30 is used for information transmission between the library operating system and the host machine.

[0088] Specifically, it is located between the library operating system and the host Linux kernel, and the information transfer between the library operating system and the Linux kernel is achieved through a combination of shared memory data and information transfer commands.

[0089] The reassembly module 40 is used to receive information transmission commands and shared memory data and reassemble them into reassembly target device driver usage commands, and then pass the reassembly target device driver usage commands to the host machine to invoke the host machine driver functions.

[0090] Specifically, it resides in the host machine's Linux kernel.

[0091] This application presents a system that reuses host machine driver functionality at runtime within the library operating system. It encapsulates all device driver command interfaces into wrapper layer modules to construct an interaction window between the application and the target device driver on the host machine. It establishes decomposition, information transmission, and reassembly modules to standardize the interaction format, transmitting target device driver commands to the host machine. This enables the target application to use micro-libraries (i.e., target device drivers) not implemented in the library operating system. This system can be used in the library operating system without modifying the target device driver, increasing the potential for ecological expansion of the library operating system's micro-libraries.

[0092] In one embodiment, such as Figure 10 As shown, the packaging layer module 10 includes: The judgment submodule 110 is used to determine whether the driver command is a target device driver command.

[0093] The first submodule 120 is used to pass the target device driver usage command to the reassembly module.

[0094] The second submodule 130 is used to pass commands from non-target device drivers to non-target micro-libraries.

[0095] Specifically, non-target device driver commands will connect to the original micro-libraries or other micro-libraries in the library operating system and run these driver commands in the original way of the library operating system.

[0096] Specifically, the internal composition of the wrapper layer module 10 is modular, consisting of command interfaces (such as open, read, etc.), and more implementation sub-modules can be added incrementally.

[0097] One possible approach is to use a wrapper function to wrap the command interface of all device drivers in the original library operating system, and replace the original interface with the wrapped interface. The judgment function of the judgment submodule 110 is used to branch into two implementation submodules. The first submodule 120 is connected to the decomposition module 20 and passes the usage commands of the target driver to the decomposition module 20. The second submodule 130 is connected to the interface implementation of Unikernel and passes the usage commands of non-target device drivers to non-target micro-libraries.

[0098] Unikernel is a technology that tightly integrates applications with the operating system kernel and libraries. It generates a single executable image by statically linking the application and its required libraries, drivers and other components into a streamlined kernel.

[0099] In one embodiment, such as Figure 11 As shown, the information transmission module 30 includes: The transfer submodule 310 is used to synchronize information between the library operating system and the host machine.

[0100] Specifically, the transmission submodule 310 sets the structure of the information transmission command to achieve information synchronization between the decomposition module and the reassembly module, and further to achieve information synchronization between the library operating system and the host machine. The transmission submodule 310 is also used to pass the return value of the driver command to the application program.

[0101] The shared submodule 320 is used to provide an interactive format for shared memory data in order to enable the sharing of shared memory data.

[0102] Specifically, the shared submodule 320 sets the interaction format for shared memory data. The interaction format is a data structure known to both the decomposition module and the reassembly module, which is used to ensure that shared memory data can be correctly written to shared memory and that read shared memory data can be correctly reassembled.

[0103] The effectiveness of the above-described method and system of the present invention will be verified below with reference to specific embodiments.

[0104] Design a target driver that provides a series of common device driver function interfaces, but only implements parameter checking and verification. When using this driver for testing, the resulting test time can be considered as including only the information transmission time, excluding any driver processing and device interaction time. This result will directly show the impact of the architecture on information transmission time. For comparison, Linux system calls are chosen as the benchmark for information transmission time. The test program executes 1000 different system calls (open, close, read, write, lseek, fstat) both using the method and system described above and directly on Linux.

[0105] See Figure 12 The results show that, compared to the native Linux implementation, the method and system of this invention introduce varying degrees of performance overhead for different operations. `open` and `close` increased by 43.1% and 51.7%, respectively. This is mainly because these operations involve a complete cross-virtual machine command passing process. The overhead introduced by other interfaces is approximately equivalent to that of an empty libcall, indicating that the overhead mainly comes from the command forwarding mechanism rather than data movement. Moreover, the final result is about half the overhead of a simple syscall; however, the method and system of this invention involve not only switching between kernel mode and user on the host, but also switching between guest and host. Therefore, the introduction of this overhead is entirely acceptable.

[0106] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0107] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0108] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for reusing host machine driver functionality during library operating system runtime, characterized in that, include: Receive driver usage commands, and find the target device driver usage command from the driver usage commands; The target device driver is decomposed using commands to obtain information transmission commands and shared memory data. According to the information transmission command, the shared memory data is written into the shared memory; Read the shared memory data, reassemble the information transmission command and the shared memory data to obtain the reassembled target device driver usage command; The recombined target device driver is passed to the host machine using a command to invoke the host machine's driver functions.

2. The method according to claim 1, characterized in that, The method for finding the target device driver usage commands from the driver usage commands includes: Obtain the target device information list and the first and second parameters of the driver command; Compare the first parameter with the parameters in the target device information list; When a parameter matching the first parameter is found in the target device information list, the driver usage command is classified as a target device driver usage command.

3. The method according to claim 2, characterized in that, The method for obtaining the target device information list includes: Receive target device information input from the target device; Obtain the path name and file descriptor of the target device driver from the target device information; Store the path name of the target device driver and the file descriptor of the target device driver in the target device information list.

4. The method according to claim 1, characterized in that, The method for decomposing the target device driver using commands includes: The list of uncertain parameters in the target device driver usage command is decomposed into shared memory data; The non-shared memory data in the target device driver usage command is decomposed into a unified information transmission command.

5. The method according to claim 1, characterized in that, The method for writing the shared memory data into shared memory includes: Obtain the starting address and length of the shared memory data in the information transmission command; Based on the shared memory data start address and the shared memory data start address length, the shared memory data is written into the corresponding location in the shared memory according to the set interaction format.

6. The method according to claim 1, characterized in that, The method for reading the shared memory data includes: Obtain the starting address and length of the shared memory data in the information transmission command; Based on the starting address and length of the shared memory data, the data is read from the corresponding location in the shared memory.

7. The method according to claim 1, characterized in that, The method for reassembling the information transmission command and the shared memory data includes: The shared memory data is parsed according to the set interaction format. The parsed shared memory data is then reassembled with the information transmission command.

8. A system for reusing host machine driver functionality at runtime in a library operating system, characterized in that, include: The wrapper layer module is used to identify and classify all driver usage commands in the library operating system, and to find the target device driver usage commands. The decomposition module is used to receive commands from the target device driver and decompose them into information transmission commands and shared memory data. The information transfer module is used for information transfer between the library operating system and the host machine; The reassembly module is used to receive information transmission commands and shared memory data and reassemble them into reassembly target device driver usage commands, and then transmit the reassembly target device driver usage commands to the host machine to invoke the host machine driver functions.

9. The system according to claim 8, characterized in that, The packaging layer module includes: The determination submodule is used to determine whether the driver command is a target device driver command; The first submodule is used to pass the target device driver usage commands to the reassembly module; The second submodule is used to pass commands from non-target device drivers to non-target micro-libraries.

10. The system according to claim 8, characterized in that, The information transmission module includes: The transfer submodule is used to synchronize information between the library operating system and the host machine; The shared submodule provides an interactive format for shared memory data to enable the sharing of shared memory data.

Images