Virtual file construction method and system for microkernel architecture

Abstract

The application provides a virtual file construction method and system for a microkernel architecture, comprising the following steps: S1, using process isolation abstraction, placing file system instances in different processes, and interacting through an inter-process communication mechanism to isolate each element of the file system from each other; S2, hierarchizing and modularizing code according to file system semantics; S3, modifying the way that musl-libc adapts to the microkernel, so that programs that dynamically link libc do not need to be modified and can be used in the system; and S4, starting the file system instance in a lazy manner. The application analyzes the support of the file system in the existing microkernel and their shortcomings, adopts a new technical means, and proposes a brand-new microkernel file system architecture; the system application program is binary compatible in the file system interface, and has good scalability and security characteristics.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of virtual machines, in particular, to a virtual file construction method and system for a microkernel architecture. BACKGROUND

[0002] A file system (FS) is one of the bridges between computer hardware and software, which converts the data structure stored on the hard disk into a software abstraction in the form of files and directories for application programs. The file system provides a series of standard interfaces for operating files and directories, so that applications with persistent requirements can conveniently achieve persistent support. In the traditional macrokernel and hybrid kernel architecture, the file system itself is in the kernel state, and the file operation is completed by diving into the kernel through file-related system calls. In the microkernel scenario, the kernel part is only responsible for the most basic operating system modules, which mainly include memory management, thread scheduling, and inter-process communication. Other system components, including the file system, will be implemented in the user space process. The file system itself also depends on many other system component services, including disk drivers. Placing the file system itself in the user space will make the software architecture and dependency relationship in the entire system more complex, in addition to which isolation and fault tolerance will become new challenges.

[0003] With the interweaving of operating system industry and academic achievements, more and more industrial microkernels have entered people's field of vision. The microkernel architecture has the following obvious differences from the well-known macrokernel architecture. As the name implies, in the microkernel architecture, the kernel space works relatively lightly, and the functions originally in the macrokernel architecture are moved up to the user space. Secondly, the interaction model of the microkernel also has obvious differences from the macrokernel. Since many functions are placed in the user space, in order to obtain specific operating system service functions, the application program must use the inter-process communication mode, rather than the mode of returning after diving into the kernel through system calls in the macrokernel. Thirdly, compared with the macrokernel architecture, the microkernel architecture moves the kernel module functions to the user space, so that the kernel part of the microkernel lacks more semantics than the macrokernel, such as the file system, and the file descriptor and other semantics and structures. The microkernel has many unique advantages compared with the macrokernel: first, due to the single responsibility of the kernel, most of the system function extensions will be implemented in the form of application programs in the system, which brings a lot of convenience for dynamic expansion of system functions and hot updates; second, when unforeseen errors occur in the system, these errors will be isolated in one or several application programs, and will not cause the entire system to crash, which brings a prior advantage for implementing fault tolerance and isolation features.

[0004] An important feature of microkernel is that the system has more inter-process communication when getting system services than macrokernel, and these inter-process communications will cause the response time of a function to be longer. At present, many academic works optimize inter-process communication, so that the time consumption of a single microkernel inter-process communication is about several hundred clock cycles, compared with the overhead of application logic itself, the overhead of inter-process communication is no longer a bottleneck, so that the microkernel provides more system features while ensuring similar performance to macrokernel.

[0005] In terms of file system, there are many related works in the research and industrial fields that provide user-mode file system function support for application programs in the microkernel scenario. Among them, the user-mode driver is a major part, and using user-mode libraries to access storage devices through the kernel is one way, such as interacting with NVMe devices through SPDK. In addition, some drivers that interact with devices through MMIO can also be decoupled directly into user mode, so that they can complete the main functions of the driver in user mode, such as eMMC drivers interacting with sd card devices. Another aspect is the system architecture and interface. Some microkernels on the market use a macrokernel-like aggregate design, and some use a separately designed single-distributed architecture. These systems all provide system-specific interfaces, which means that user programs need to be rewritten using these interfaces to run on the system.

[0006] Patent document CN112698918A (application number: CN202110013164.8) discloses a virtual machine file generation method and device based on a construction environment. The method includes: collecting the software and hardware configurations and software dependencies required by the constructed construction environment; generating a configuration file in a preset format according to the software and hardware configurations and the software dependencies; creating a virtual machine, and creating virtual machine hardware and virtual machine software corresponding to the software and hardware configuration information and the software dependency information in the virtual machine according to the software and hardware configuration information and the software dependency information in the configuration file; after completing the creation of the virtual machine hardware and the virtual machine software in the virtual machine, saving the virtual machine containing the virtual machine hardware and the virtual machine software to generate a virtual machine file. However, the invention does not provide a glue layer between musl-libc and third-party file system libraries, making it suitable for microkernels. SUMMARY

[0007] In view of the defects in the prior art, the purpose of the present application is to provide a virtual file construction method and system for microkernel architecture.

[0008] According to the virtual file construction method for microkernel architecture provided by the present application, the following steps are included:

[0009] Step S1: using process isolation abstraction, putting file system instances in different processes, interacting through inter-process communication mechanism, so that each element of the file system is isolated from each other;

[0010] Step S2: hierarchizing and modularizing the code according to file system semantics

[0011] Step S3: modifying the way of adapting musl-libc to microkernel, so that programs dynamically linked with libc can be put into the system without modification;

[0012] Step S4: starting the file system instance in a lazy way.

[0013] Preferably, in the step S1:

[0014] The file system is split into user-mode disk driver service, partition mounting service, and specific file service interface service;

[0015] In the step S2:

[0016] A lightweight virtual file system module is written to accommodate all file system requests and handle the logic in these requests that is independent of specific file system formats, and is provided to file system porters in the form of a static link library, and the porters fill in the function pointer list according to the required file system interfaces in the interface list to complete the porting.

[0017] Preferably, in the step S3:

[0018] An interface compatible with the Portable Operating System Interface is provided, and is called by the application in the form of dynamic linking, and the specific technical method is as follows: in the existing musl-libc source code, the inter-process communication logic of the microkernel completing the file system logic is transplanted, and is compiled into a gcc-wrapper and a dynamic link library libc.so, so that the application can use the custom function behavior in dynamic linking and static linking, and these functions maintain the original compatibility of the Portable Operating System Interface;

[0019] For file system related interfaces that require kernel participation, the related interfaces are implemented completely when the kernel provides thread scheduling and memory management related interfaces, and the specific details are as follows: an asynchronous communication mechanism between the kernel and the user mode is established through a ring queue and a pull mechanism, and the page fault event information in the kernel is transmitted to the user mode file system instance, and the file system instance reads the information and calls the page table interface provided by the kernel to perform user mode page fault processing;

[0020] In the step S3:

[0021] When an application needs to use a specific file system instance, the specific file system instance is loaded by the global application manager, and when the file system instance is already running in the system, a communication channel is directly established between the application and the file system.

[0022] Preferably, in order to ensure the isolation of the system, the file system states between the applications should be isolated from each other, including that the states of two unrelated processes should not be accessed through the file system, and unrelated requests should not have performance impact;

[0023] In the portable operating system interface design, the file descriptor is generated by a system call, and then the file system is accessed through a series of system calls for operating the file descriptor. The file descriptor is divided into three types, one is a file type descriptor, the second is a directory type descriptor, and the third is other descriptors. In the design of Linux, the descriptor generated by the system call may share the offset data between different processes. The offset data should be saved in the file system server rather than in the application side.

[0024] Preferably, the descriptor information saved in the application side includes an integer index and the type information of the file descriptor; the entry saved in the service side contains the descriptor offset information; and the virtual node saved in the service side.

[0025] The index of the file descriptor is generated by the application and sent to the file system service for recording. The file system service side generates an entry corresponding to each descriptor, and different entries pointing to the same file are combined to point to a virtual node. On the file system service side, each entry corresponds to a file descriptor on the application side, each virtual node corresponds to a file on the disk, and there is a many-to-one mapping relationship between the entry and the virtual node.

[0026] The application uses the file system through the portable operating system interface compatible interface, and the code for converting the call into the corresponding inter-process communication is encapsulated into musl-libc. The data structure related to the file descriptor is divided into the application part and the service side part, and the operation of the file descriptor is completed by the application and the service. The data structure on the file system service side is saved according to the id of the application program, which ensures the data isolation and performance isolation between different application processes.

[0027] The function of the file system decorator part is mainly to receive and distribute inter-process communication requests. The file system general module is located between the decorator and the specific file system, and is an optional module. The decorator and the specific file system are encapsulated into a static link library, and a list of function pointers related to the specific file system is reserved, thereby minimizing the repeated code in the file system porting process.

[0028] Each file system implementation contains a set of file system decorators and a file system common module, and a file system implementation.

[0029] During coding, if a developer needs to extend the file system common module, the code of the corresponding module is written and connected in the file system common module part; if the developer needs to add a new file system implementation, the writing is performed according to a function pointer list in the file system decorator, and the file system decorator is combined in a static linking manner; the framework abstracts the common code logic of the file system into the file system decorator;

[0030] During execution, the application program libc module sends a user's portable operating system interface request to the file system management service in the form of inter-process communication; the file system management service starts a file system instance according to a path parameter in a lazy manner, and different file system instances are placed in different processes to isolate errors; then, the file system service processes a specific request, and the file system service includes the file system decorator, the file system common module, and a file system implementation; after the data structure corresponding to the request is updated in the file system service process, the running result information is returned to the application program.

[0031] According to the virtual file construction system for the microkernel architecture provided by the application, the system comprises:

[0032] Module M1: abstractly, the file system instance is placed in different processes, and the file system elements are isolated from each other through an inter-process communication mechanism;

[0033] Module M2: the code is layered and modularized according to file system semantics

[0034] Module M3: the musl-libc is adapted to the microkernel, so that a program dynamically linked with libc can be used in the system without modification;

[0035] Module M4: the file system instance is started in a lazy manner.

[0036] Preferably, in the module M1:

[0037] The file system is split into a user state disk drive service, a partition mounting service, and a specific file service interface service.

[0038] In the module M2:

[0039] A lightweight virtual file system module is written to accommodate all file system requests and handle the logic in these requests that is independent of the specific file system format, and is provided to file system porters in the form of a static library, and the porters fill in the function pointer list in the form of fill-in-the-blank to complete the porting according to the file system interfaces required in the interface list.

[0040] Preferably, in the module M3,

[0041] An interface compatible with the portable operating system interface is provided, and is called by an application in the form of dynamic linking, and the specific technical method is as follows: in the existing musl-libc source code, the inter-process communication logic of the microkernel completing the file system logic is compiled into a gcc-wrapper and a dynamic link library libc.so, so that the application can use the customized function behavior in dynamic linking and static linking, and the functions remain the original compatibility of the portable operating system interface;

[0042] For file system related interfaces that need the participation of the kernel, the related interfaces are implemented completely when the kernel provides thread scheduling and memory management related interfaces, and the specific details are as follows: an asynchronous communication mechanism between the kernel and the user state is established through a ring queue and a pull mechanism, and the page fault event information in the kernel is transmitted to the user state file system instance, and the file system instance transmits the page fault event information to the user state file system instance by reading the information and calling the page table interface provided by the kernel to perform user state page fault processing;

[0043] In the module M3,

[0044] When an application actually needs to use a specific file system instance, the global application manager loads the specific file system instance, and when the file system instance is already running in the system, a communication channel between the application and the file system is directly established.

[0045] Preferably, in order to ensure the isolation of the system, the file system states of the applications should be isolated from each other, including that unrelated processes should not be able to access each other's process states through the file system, and unrelated requests should not have performance impact;

[0046] In the design of the portable operating system interface, file descriptors are generated by system calls, and then a series of system calls for operating file descriptors are used to access the file system, and the file descriptors are divided into three categories: file type descriptors, directory type descriptors, and other descriptors; in the design of Linux, the descriptors generated by system calls may share offset data between different processes, and the offset data should be saved in the file system server rather than in the application side.

[0047] Preferably, the descriptor information saved in the application side includes an integer index and type information of the file descriptor; the entry saved in the service side contains descriptor offset information; and the virtual node saved in the service side.

[0048] The index of the file descriptor is generated by the application and sent to the file system service for recording. The file system service side generates a corresponding entry for each descriptor, and different entries pointing to the same file are combined to point to a virtual node. On the file system service side, each entry corresponds to a file descriptor on the application side, each virtual node corresponds to a file on the disk, and there is a many-to-one mapping relationship between the entry and the virtual node.

[0049] The application uses the file system with a portable operating system interface compatible interface, and the call is converted into corresponding inter-process communication code encapsulated into musl-libc. The data structure related to the file descriptor is divided into the application part and the service side part, and the operation on the file descriptor is completed by the application and the service. The data structure on the file system service side is saved according to the id of the application program, which ensures the data isolation and performance isolation between different application processes.

[0050] The function of the file system decorator part is mainly to receive and distribute inter-process communication requests. The file system general module is located between the decorator and the specific file system and serves as an optional module. The decorator and the specific file system are encapsulated into a static link library, and a list of function pointers related to the specific file system is reserved, thereby minimizing the repeated code in the file system porting process.

[0051] Each file system implementation includes a set of file system decorators and file system general modules, and a file system implementation.

[0052] If the developer needs to extend the file system general module during the coding process, the corresponding module code is written and connected in the file system general module part. If the developer needs to add a new file system implementation, the code is written according to the function pointer list in the file system decorator and combined with the file system decorator in a static link manner. The framework abstracts the common code logic of the file system into the file system decorator.

[0053] During the execution process, the application program libc module converts the user's portable operating system interface request into an inter-process communication form and sends it to the file system management service; the file system management service starts the file system instance according to the path parameter, and different file system instances are placed in different processes to isolate errors; then the file system service processes the specific request, and the file system service includes a file system decorator, a file system general module and a file system implementation; after the file system service process updates the data structure corresponding to the request, the running result information is returned to the application program.

[0054] Compared with the prior art, the present application has the following beneficial effects:

[0055] 1. The present application analyzes the support of the existing microkernel file system and their shortcomings, and adopts a new technical means to propose a new microkernel file system architecture;

[0056] 2. The present application provides a glue layer between musl-libc and the third-party file system library, which makes it suitable for microkernel, not only makes the system application binary compatible in the file system interface, but also has good scalability and security characteristics;

[0057] 3. The present application is suitable for most microkernel file system development scenarios, making the expansion of microkernel file system function more efficient and convenient. BRIEF DESCRIPTION OF DRAWINGS

[0058] Other features, objects and advantages of the present application will become more apparent from the following detailed description of non-limiting embodiments with reference to the attached drawings:

[0059] Figure 1 is a mapping relationship diagram of data structure;

[0060] Figure 2 is a file system framework code structure;

[0061] Figure 3 is a control flow and data flow diagram. DETAILED DESCRIPTION

[0062] The present application will be described in detail below with reference to specific embodiments. The following embodiments will help those skilled in the art to further understand the present application, but do not limit the present application in any form. It should be pointed out that, for those skilled in the art, without departing from the concept of the present application, a number of changes and improvements can be made. These all belong to the protection scope of the present application.

[0063] Example 1:

[0064] The method proposed in the present application mainly solves the following problems:

[0065] 1. How to provide a POSIX compatible microkernel virtual file system? Can applications be ported to the microkernel without modifying the source code?

[0066] 2. How to efficiently extend and customize the microkernel file system function?

[0067] 3. How to use the inter-process communication mechanism of the microkernel to provide isolation and fault tolerance features for file system components?

[0068] A file system architecture scheme in a microkernel scenario, comprising:

[0069] 1. Binary compatibility is implemented on the microkernel file system interface, and the application is modified to adapt to the microkernel by modifying musl-libc, so that programs that dynamically link libc can be used without modification, which means that binary files compiled on the corresponding architecture of Linux can be directly run on the new system;

[0070] 2. For file system functions that require kernel cooperation, the application proposes a kernel-user interaction logic and thread migration model suitable for most scenarios, which can implement cross-process user-mode page fault logic, etc. under the model;

[0071] 3. In order to reduce the porting burden and repeated code, the application proposes to provide the virtual file system layer in the form of a static library for porters to use, and porters only need to fill in the function list according to the specific file system specification and the third-party code being ported;

[0072] 4. In order to achieve fault tolerance and save system runtime resources, the application proposes to use the lazy start file system instance method, which avoids the waste of memory and CPU resources caused by starting all instances at once, and also provides a natural fault tolerance recovery condition;

[0073] 5. The application proposes a complete architecture scheme suitable for the file system scenario on the microkernel.

[0074] The application contains the following technical points, as shown in Figures 1-3

[0075] 1. Use process isolation abstraction to place file system instances in different processes and interact through inter-process communication mechanisms to isolate each element of the file system from each other, and the specific technical method is: split the file system into user-mode disk drive services, partition mounting services, and specific file service interface services;

[0076] ​2. In order to achieve fault-tolerant recovery mechanism, the file system instance adopts the form of lazy start, specifically: when the application actually needs to use a specific file system instance, the global application manager loads the specific file system instance, and when the file system instance is already running in the system, the communication channel between the application and the file system is directly established, which can reduce the number of unnecessary file system instances in the system at runtime, and can restart the application manager after the instance accidentally exits;

[0077] 3. In order to migrate the user program without modification, our system should provide POSIX compatible interface and call it with dynamic link, the specific technical method is: in the existing musl-libc source code, the microkernel completes the inter-process communication logic of the file system logic, and compiles it into a gcc-wrapper and a dynamic link library libc.so, so that the application can use the custom function behavior when dynamically linked and statically linked, and these functions maintain the original POSIX compatibility;

[0078] 4. For file system related interfaces that require kernel participation, such as mmap, when the kernel provides thread scheduling and memory management related interfaces, it can be implemented completely, the specific details are as follows: through the ring queue and polling mechanism to establish an asynchronous communication mechanism between the kernel and the user state, the page fault event information in the kernel is transmitted to the user state file system instance, and the file system instance reads the information and calls the page table interface provided by the kernel to handle the user state page fault;

[0079] 5. In order to make the file system function can be efficient expansion, through the code according to the file system semantics layering and modularization, the biggest reduce the porting difficulty of expansion function, the specific details are as follows: write a lightweight virtual file system module to receive all file system requests and handle the logic in these requests that is independent of the specific file system standard, and provide it to the file system porting personnel in the form of static link library, the porting party only needs to fill in the function pointer list according to the few file system interfaces required in the interface list in the form of fill-in-the-blanks to complete the porting.

[0080] The following is a supplementary description of the above technical points:

[0081] Since file system is a stateful system, e.g. information in file descriptor and current working directory, and it is a one-to-many model in general, i.e. one file system instance needs to serve multiple applications, how to split these states and where to save these states in the system becomes a problem to be considered. In order to guarantee the isolation of the system, the file system states among these applications should be isolated from each other, which includes that unrelated processes should not be able to access each other's process states through file system, and unrelated requests should not have performance impact on each other.

[0082] In POSIX design, file descriptor is generated by open and other system calls, and then file system is accessed through a series of system calls operating file descriptor. File descriptor can be divided into three categories, one is file type descriptor, two is directory type descriptor, and three is other descriptor (including pipe, socket, etc.). The key state in file and directory type descriptor is offset, which guarantees that different fragments are read continuously by multiple calls of read operation. In particular, in the design of Linux, the descriptor generated by some system calls such as fork may share offset data among different processes, so the offset data should be saved in file system server rather than in application side.

[0083] In the specific design of the present solution, the following several key data structures are included: descriptor information saved in application side, which usually includes an integer index and file descriptor type information; entry saved in service side, which contains descriptor offset information; virtual node saved in service side. Figure 1 is a possible mapping relationship of these data structures in runtime system:

[0084] The index of file descriptor (integer fd) is generated by application and sent to file system service for recording, and file system service side will generate an entry corresponding to each descriptor, and different entries pointing to the same file will be merged to point to a virtual node (vnode). In other words, on file system service side, each entry corresponds to a file descriptor on application side, each virtual node corresponds to a file on disk, and there is a many-to-one mapping relationship between entry and virtual node.

[0085] In this implementation, the application can use the file system with POSIX compatible interface, the conversion of the call into the corresponding inter-process communication code is encapsulated into musl-libc, the data structure related to the file descriptor is divided into the application part and the service side part, and the operation on the file descriptor is completed by the application and the service cooperatively. In particular, the data structure of the file system service side is saved according to the id of the application program, so as to ensure the data isolation and performance isolation between different application processes.

[0086] The present solution additionally proposes some recommended items related to the code structure to maximize the scalability and ease of use of the file system framework. The solution is as shown in Figure 2

[0087] The function of the file system decorator part is mainly to receive and distribute the inter-process communication request; the file system general module such as page cache is located between the decorator and the specific file system, and is an optional module. The above two can be encapsulated into a static link library, and only the function pointer list related to the specific file system is reserved, thereby minimizing the repeated code in the file system porting process.

[0088] Each file system implementation includes a set of file system decorators and file system general modules, and a file system implementation (file system 1 or file system 2, etc.).

[0089] In the coding process: if the developer needs to extend the file system general module, the code of the corresponding module is written and connected in the “file system general module” part; if the developer needs to add a new file system implementation, the code is written according to the function pointer list in the file system decorator, and is combined with the file system decorator in a static link manner. This framework abstracts the common code logic of most file systems into file system decorators, thereby improving the code reuse rate and reducing the writing of repeated code. For example, the function pointer list in the decorator and the page cache extension in the general module are all codes that can be shared between different file systems.

[0090] In the execution process: the application libc module sends the user's POSIX request to the file system management service in the form of inter-process communication by converting it; the file system management service starts the file system instance according to the path parameter, and different file system instances are placed in different processes to isolate errors; then the file system service (including the file system decorator, the file system general module, and a file system implementation) processes the specific request; after updating the data structure (entry, vnode, etc.) corresponding to the request in the file system service process, the running result information is returned to the application.

[0091] Technical data interpretation: ​

[0092] FS: File System, file system

[0093] MMIO: Memory-mapped I / O, memory-mapped I / O

[0094] SPDK: Storage Performance Development Kit, storage performance development kit

[0095] POSIX: Portable Operation System Interface, portable operation system interface

[0096] Example 2:

[0097] Embodiment 2 is a preferred example of Embodiment 1, to illustrate the present application more specifically.

[0098] Below we take a specific file system request (openat) as an example to illustrate how the control flow and data flow work in our architecture.

[0099] The semantics of an openat request is to open a corresponding file descriptor through a given path, when the path is valid and corresponds to a directory entry, and then the content of the file can be accessed and modified through this file descriptor.

[0100] In the framework of the present solution, an openat request involves three file system components: file system management service, file system service, and application. The request is first sent by the client to the file system management service through inter-process communication with the path, the file system management service parses the path according to the path to obtain the file system service instance corresponding to the path, and then sends the corresponding capability back to the requester, and the requester establishes a connection with the corresponding file system service through the capability; the file system service side accesses the disk data structure to find the corresponding directory entry, and if the opening is successful, some related data structures are created in the file system service, and the request status is returned through inter-process communication.

[0101] For the special POSIX call mmap, the processing flow is as follows:

[0102] 1. The application program calls the mmap interface, registers a block of physical memory area in the kernel marked for mmap use, and sends inter-process communication to the file system service with memory-related parameters;

[0103] 2. The file system service binds a page fault handling function to it according to the parameter content;

[0104] 3. The application returns to execute other code and triggers a page fault via a memory access operation;

[0105] 4. The page fault causes the thread to trap to the kernel, which finds the corresponding memory region and switches to a page fault handling function within the file system service, thus enabling user-mode page fault handling;

[0106] 5. After the page fault is handled, the code that triggered the page fault is returned to and execution continues.

[0107] So far, we have introduced how the framework handles the compatibility of general and special POSIX interfaces respectively.

[0108] Those skilled in the art know that, in addition to implementing the system, device and each module thereof provided by the present application in the form of pure computer readable program code, the same program can also be realized in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers and embedded microcontrollers by logically programming the method steps. Therefore, the system, device and each module thereof provided by the present application can be considered as a hardware component, and the modules included therein for implementing various programs can also be considered as structures within the hardware component; the modules for implementing various functions can also be considered as both software programs for implementing methods and structures within hardware components.

[0109] The specific embodiments of the present application are described above. It needs to be understood that the present application is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essential content of the present application. The embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily without conflict.

Claims

1. A virtual file construction method for a microkernel architecture, characterized by, Comprise: Step S1: using process isolation abstraction, put the file system instance in different processes, interact through inter-process communication mechanism, so that the elements of the file system are isolated from each other; Step S2: code is layered and modularized according to file system semantics; Step S3: modify the way musl-libc adapts microkernel, so that programs that dynamically link libc do not need to be modified to use in the system; Step S4: start the file system instance in a lazy way.

2. The microkernel architecture-oriented virtual file construction method according to claim 1, characterized in that: In the step S1: The file system is divided into user-mode disk driver service, partition mounting service, and specific file service interface service; In the step S2: A lightweight virtual file system module is written to accommodate all file system requests and handle the logic in these requests that is independent of the specific file system format, and is provided to file system porters in the form of a static library. The porters fill in the function pointer list according to the required file system interfaces in the interface list to complete the porting.

3. The microkernel architecture-oriented virtual file construction method according to claim 1, characterized in that: In the step S3: An interface compatible with the Portable Operating System Interface is provided, and is called by the application in the form of dynamic linking. The specific technical method is as follows: in the existing musl-libc source code, the inter-process communication logic of the microkernel is inserted to complete the file system logic, which is compiled into a gcc-wrapper and a dynamic library libc.so, so that the application can use the custom function behavior in dynamic and static linking, and these functions maintain the original Portable Operating System Interface compatibility; For file system related interfaces that require kernel participation, implement the thread scheduling and memory management related interfaces provided by the kernel, and the specific details are as follows: establish an asynchronous communication mechanism between the kernel and the user mode file system instance through a ring queue and a pull mechanism, and pass the page fault event information in the kernel to the user mode file system instance. The file system instance reads this information and calls the page table interface provided by the kernel to handle the user mode page fault; In the step S3: When the application uses a specific file system instance, the global application manager loads the specific file system instance, and when the file system instance is already running in the system, the communication channel between the application and the file system is established directly.

4. The microkernel architecture-oriented virtual file construction method according to claim 1, characterized in that: In order to ensure the isolation of the system, the file system state of the application should be isolated from each other, including that unrelated processes cannot access each other's process state through the file system, and unrelated requests have no performance impact. In the portable operating system interface design, file descriptors are generated by system calls, and then file system access is completed through a series of system calls for operating file descriptors. File descriptors are divided into three categories: file type descriptors, directory type descriptors, and other descriptors, including pipes or sockets. In the design of Linux, the descriptors generated by system calls may share offset data between different processes. The offset data should be saved in the file system server rather than the application side.

5. The microkernel architecture-oriented virtual file construction method according to claim 1, characterized in that: The descriptor information saved on the application side includes an integer index and type information of the file descriptor; the entry saved on the service side contains descriptor offset information; and the virtual node saved on the service side; The index of the file descriptor is generated by the application and sent to the file system service for recording. The file system service side generates a corresponding entry for each descriptor, and different entries pointing to the same file are merged to point to a virtual node. Each entry corresponds to a file descriptor on the application side, each virtual node corresponds to a file on the disk, and there is a many-to-one mapping relationship between the entry and the virtual node; The application uses the file system through a portable operating system interface compatible interface, and the corresponding inter-process communication code is encapsulated into musl-libc. The data structure related to the file descriptor is divided into the application part and the service side part, and the operation of the file descriptor is completed by the application and the service side. The data structure of the file system service side is saved according to the id of the application program, which ensures the data isolation and performance isolation between different application processes; The function of the file system decorator part is mainly to receive and distribute inter-process communication requests. The file system general module is located between the decorator and the specific file system, and is an optional module. The decorator and the specific file system are encapsulated into a static link library, and a list of function pointers related to the specific file system is reserved, thereby minimizing the repeated code in the file system porting process; Each file system implementation includes a set of file system decorators and file system general modules, and a file system implementation; If the developer needs to extend the file system general module during the coding process, the corresponding module code is written and connected in the file system general module part; If the developer needs to add a new file system implementation, the code is written according to the function pointer list in the file system decorator, and is combined with the file system decorator in a static link manner. The framework abstracts the common code logic of the file system into the file system decorator. During execution, the application program libc module converts the user's portable operating system interface request into an inter-process communication form and sends it to the file system management service; the file system management service starts a file system instance according to a path parameter in a lazy manner, and different file system instances are placed in different processes to isolate errors; then the file system service processes a specific request, and the file system service includes a file system decorator, a file system general module and a file system implementation; after updating the corresponding data structure in the file system service process, the running result information is returned to the application program.

6. A virtual file construction system oriented to a microkernel architecture, characterized by, Comprise: Module M1: abstract process isolation, place file system instances in different processes, interact through inter-process communication mechanism, and isolate each element of the file system from each other; Module M2: hierarchize and modularize the code according to file system semantics; Module M3: modify the musl-libc adaptation microkernel method, so that programs that dynamically link libc do not need to be modified and can be used in the system; Module M4: start the file system instance in a lazy manner.

7. The microkernel architecture-oriented virtual file construction system according to claim 6, characterized in that: In the module M1: The file system is divided into a user-mode disk driver service, a partition mounting service and a specific file service interface service; In the module M2: A lightweight virtual file system module is written to accommodate all file system requests and handle the logic in these requests that is independent of the specific file system standard, and is provided to file system porters in the form of a static library, and the porters fill in the function pointer list according to the required file system interfaces in the interface list to complete the porting.

8. The microkernel architecture-oriented virtual file construction system according to claim 6, characterized in that: In the module M3: An interface compatible with the portable operating system interface is provided, and is called by the application program in the form of dynamic linking, and the specific technical method is as follows: in the existing musl-libc source code, the inter-process communication logic of the microkernel is inserted to complete the file system logic, and is compiled into a gcc-wrapper and a dynamic library libc.so, so that the application program can use the customized function behavior in dynamic and static linking, and these functions maintain the original portable operating system interface compatibility; For file system related interfaces that require kernel participation, complete implementation when the kernel provides thread scheduling and memory management related interfaces, and the specific details are as follows: an asynchronous communication mechanism between the kernel and the user mode is established through a ring queue and a pull mechanism, and the page fault event information in the kernel is transmitted to the user mode file system instance, and the file system instance processes the user mode page fault by reading the information and calling the page table interface provided by the kernel; In the module M3: When the application program uses a specific file system instance, the global application program manager loads the specific file system instance, and when the file system instance is already running in the system, a communication channel between the application program and the file system is established directly.

9. The microkernel architecture oriented virtual file system construction system according to claim 6, characterized in that: In order to ensure the isolation of the system, the file system state between the applications should be isolated from each other, including that the process state of two unrelated processes cannot be accessed through the file system, and unrelated requests have no performance impact; In the portable operating system interface design, the file descriptor is generated by the system call, and then the file system access is completed through a series of system calls for operating the file descriptor. The file descriptor is divided into three categories: the first is the descriptor of the file type, the second is the descriptor of the directory type, and the third is other descriptors, including pipes or sockets. In the design of Linux, the descriptor generated by the system call may share the offset data between different processes. The offset data should be saved in the file system server rather than the application side.

10. The microkernel architecture oriented virtual file system construction system according to claim 6, characterized in that: The descriptor information saved on the application side includes an integer index and the type information of the file descriptor; the entry saved on the service side contains the descriptor offset information; and the virtual node saved on the service side; The index of the file descriptor is generated by the application and sent to the file system service for recording. The file system service side will generate an entry corresponding to each descriptor, and different entries pointing to the same file will be merged to point to a virtual node. Each entry corresponds to a file descriptor on the application side, each virtual node corresponds to a file on the disk, and the entry and the virtual node are in a many-to-one mapping relationship; The application uses the file system with a portable operating system interface compatible interface, and the code for calling the corresponding inter-process communication is encapsulated into musl-libc. The data structure related to the file descriptor is divided into the application part and the service side part, and the operation of the file descriptor is completed by the application and the service side. The data structure of the file system service side is saved according to the id of the application program, which ensures the data isolation and performance isolation between different application processes; The function of the file system decorator part is mainly to receive and distribute inter-process communication requests. The file system general module is located between the decorator and the specific file system, and is an optional module. The decorator and the specific file system are encapsulated into a static link library, and the function pointer list related to the specific file system is reserved, thereby minimizing the repeated code in the file system porting process; Each file system implementation includes: a set of file system decorators and file system general modules, and a file system implementation; If the developer needs to extend the file system general module during the coding process, the corresponding module code is written and connected in the file system general module part; If the developer needs to add a new file system implementation, the code is written according to the function pointer list in the file system decorator, and is combined with the file system decorator in a static link manner. The framework abstracts the common code logic of the file system into the file system decorator. During execution, the application program libc module sends user's portable operating system interface requests to the file system management service in the form of inter-process communication; the file system management service starts file system instances according to path parameters, and different file system instances are placed in different processes to isolate errors; then the file system service processes specific requests, and the file system service includes a file system decorator, a file system general module and a file system implementation; after updating the data structure corresponding to the request in the file system service process, the file system service returns the running result information to the application program.

Images