1.本发明涉及虚拟机
技术领域：
：，具体地，涉及一种面向微内核架构的虚拟文件构建方法及系统。
背景技术：
：：2.文件系统(fs)是计算机硬件软件桥梁之一，它将硬盘上存储的数据结构，以文件和目录的形式转化为软件抽象，供应用程序使用。文件系统通过提供一系列标准的操作文件和目录的接口，使包含有持久化需求的应用便捷地实现持久化支持。在传统的宏内核以及混合内核架构下，文件系统本身处于内核态，通过文件相关的系统调用下陷于内核完成文件操作。而微内核场景下，内核部分只负责最基础的操作系统模块，这些模块主要是：内存管理、线程调度、进程间通信。而其他的系统组件，包括文件系统，都将在用户态进程中实现。文件系统本身也依赖于其他众多的系统组件服务，包括磁盘驱动器等。将文件系统本身放在用户空间也会使整个系统内的软件架构以及依赖关系变得更为复杂，除此之外，隔离和容错也将成为新的挑战。3.随着操作系统工业与学术成果的交织，越来越多的工业微内核步入人们的视野。微内核架构与为人熟知的宏内核架构有以下一些明显的区别。顾名思义，微内核架构中，内核空间的工作相对较轻，原先在宏内核架构中的功能都将上移至用户空间。其次，微内核的交互模型与宏内核也有明显的差别，由于很多功能被放在用户空间，应用程序为了获取特定的操作系统服务功能，必须通过进程间通信的方式，而非宏内核通过系统调用下陷内核后返回的模式。其三，随着微内核架构相比宏内核架构将内核模块功能上提至用户态，使得微内核的内核部分相比宏内核缺少了更多的语义，例如微内核的内核部分没有文件系统，也就没有文件描述符等等语义和结构。微内核相比宏内核有很多独到的优势：一者，由于内核职责单一，大多数对于系统功能的扩展都会以应用程序的形式被实现在系统中，这对于动态扩展系统功能以及热更新等特性带来了很多便捷；二者，当系统中出现不可预见的错误，这些错误往往会被隔离在一个或几个应用程序之中，而不会导致整个系统的崩溃，这为实现容错以及隔离特性带来了先天的优势。4.微内核的一个重要特点在于系统在获取系统服务的时候，相比宏内核要多若干个进程间通信，而这些进程间通信会导致一个功能的响应时间变长。而当前很多学术工作针对进程间通信做出优化，使得单次微内核的进程间通信耗时约几百时钟周期，相较于应用逻辑本身的开销，进程间通信的开销不再成为瓶颈，从而让微内核提供更多的系统特性的同时保证与宏内核相近的性能。5.文件系统方面，研究界与工业界有不少相关工作在微内核场景下为应用程序提供用户态文件系统功能支持。其中用户态的驱动程序是一个主要部分，使用用户态库越过内核访问存储设备是其中一种方式，例如通过spdk与nvme设备交互。另外，一些通过mmio与设备交互的驱动程序也可以直接将其解耦放入用户态，使其在用户态完成驱动的主要功能，例如emmc驱动与sd卡设备交互。另一个方面则是系统架构和接口方面，市面上的微内核，一些使用的是类似宏内核的聚合式设计，一些则是采用另行设计的单机分布式架构，而这些无一例外提供的均是系统特有的接口，这意味着用户程序需要使用这些接口重写才能在该系统上运行。6.专利文献cn112698918a(申请号：cn202110013164.8)公开了一种基于构建环境的虚拟机文件生成方法、装置。该方法包括：采集搭建的构建环境所需要的软硬件配置和软件依赖；根据所述软硬件配置和所述软件依赖生成预设格式的配置文件；创建虚拟机，并根据所述配置文件中的软硬件配置信息及软件依赖信息在所述虚拟机中创建与所述软硬件配置信息及所述软件依赖信息相对应的虚拟机硬件与虚拟机软件；在所述虚拟机中完成所述虚拟机硬件与虚拟机软件的创建后，对包含所述虚拟机硬件与虚拟机软件的虚拟机进行保存，以生成虚拟机文件。但该发明没有为musl-libc与第三方文件系统库之间提供胶水层，使之适用于微内核。技术实现要素：7.针对现有技术中的缺陷，本发明的目的是提供一种面向微内核架构的虚拟文件构建方法及系统。8.根据本发明提供的一种面向微内核架构的虚拟文件构建方法，包括：9.步骤s1：利用进程隔离抽象，将文件系统实例放在不同进程中，通过进程间通信机制进行交互，使得文件系统各个元件之间相互隔离；10.步骤s2：将代码根据文件系统语义分层化与模块化11.步骤s3：修改musl-libc适配微内核的方式，使得动态链接libc的程序无需修改放入系统中使用；12.步骤s4：采用惰性方式启动文件系统实例。13.优选地，在所述步骤s1中：14.将文件系统拆分为用户态磁盘驱动服务、分区挂载服务、具体文件服务接口服务；15.在所述步骤s2中：16.编写一个轻量级虚拟文件系统模块收纳所有文件系统请求，并处理这些请求中与具体文件系统制式无关的逻辑，以静态链接库形式提供给文件系统移植人员，移植方根据接口列表中要求的文件系统接口，以填空形式填入函数指针列表完成移植。17.优选地，在所述步骤s3中：18.提供可移植操作系统接口兼容的接口，并以动态链接的形式交与应用程序调用，具体技术方法为：在现有的musl-libc源码中，扦插微内核完成文件系统逻辑的进程间通信逻辑，将之编译为一个gcc-wrapper与一个动态链接库libc.so，使得应用程序在动态链接与静态链接时均能够使用自定义的函数行为，并且这些函数保持了原有的可移植操作系统接口兼容性；19.针对需要内核参与的文件系统相关接口，在内核提供线程调度与内存管理相关接口时完整实现，具体细节如下：通过环形队列与拉取机制建立内核与用户态的异步通信机制，将内核中的缺页事件信息传递给用户态文件系统实例，文件系统实例通过读取该信息，通过调用内核提供的页表接口，进行用户态缺页处理；20.在所述步骤s3中：21.当应用程序切实需要使用某个具体文件系统实例时，由全局的应用程序管理器加载具体的文件系统实例，当该文件系统实例已经在系统中运行时，直接建立应用程序与文件系统的通信通道。22.优选地，为了保证系统的隔离性，应用程序之间的文件系统状态应该相互隔离，包括两个无关进程之间不应该能通过文件系统访问到各自的进程状态，以及无关的请求之间不应该有性能影响；23.在可移植操作系统接口设计中，文件描述符由系统调用产生，随后通过一系列操作文件描述符的系统调用完成对文件系统的访问，文件描述符分为三类，一是文件类型的描述符，二是目录类型的描述符，三是其他描述符；在linux的设计中，由系统调用产生的描述符可能在不同进程之间共享偏移量数据，偏移量数据应当保存在文件系统服务端而非应用程序端。24.优选地，保存在应用程序侧的描述符信息，包括一个整型索引以及文件描述符的类型信息；保存在服务侧的entry，包含描述符偏移量信息；保存在服务侧的虚拟节点。25.文件描述符的索引由应用程序产生后发送给文件系统服务进行记录，文件系统服务侧会为每个描述符生成一个对应的entry，指向同一个文件的不同entry会被合并指向一个虚拟节点；文件系统服务侧，每个entry对应应用程序侧一个文件描述符，每个虚拟节点对应一个磁盘上的文件，而entry与虚拟节点之间是一个多对一的映射关系；26.应用程序以可移植操作系统接口兼容的接口使用文件系统，将调用转化成对应进程间通信的代码被封装到musl-libc中，有关文件描述符的数据结构被分到应用部分和服务侧部分，由应用和服务协同完成对文件描述符的操作，文件系统服务侧的数据结构根据应用程序的id分别保存，保证了不同应用进程之间的数据隔离和性能隔离；27.文件系统装饰器部分的功能主要是接收和分发进程间通信请求；文件系统通用模块位于装饰器和具体文件系统之间，作为可选模块；装饰器和具体文件系统封装成一个静态链接库，保留与具体文件系统有关的函数指针列表，由此最小化文件系统移植过程中的重复代码；28.每个文件系统实现都包含：一组文件系统装饰器和文件系统通用模块，一个文件系统实现。29.编码过程中如果开发人员需要扩展文件系统通用模块，则编写对应模块的代码并在文件系统通用模块部分进行对接；如果开发人员需要添加新的文件系统实现，则根据文件系统装饰器内的函数指针列表进行编写，以静态链接的方式与文件系统装饰器进行组合；该框架将文件系统共同的代码逻辑抽象为文件系统装饰器；30.执行过程中应用程序libc模块通过将用户的可移植操作系统接口请求转化成进程间通信形式发送给文件系统管理服务；文件系统管理服务根据路径参数惰性启动文件系统实例，不同的文件系统实例被分放在不同的进程中，以此达到隔离错误的目的；随后文件系统服务处理具体请求，件系统服务包括文件系统装饰器、文件系统通用模块、一个文件系统实现；文件系统服务进程内更新该请求对应的数据结构后，将运行结果信息返回给应用程序。31.根据本发明提供的一种面向微内核架构的虚拟文件构建系统，包括：32.模块m1：利用进程隔离抽象，将文件系统实例放在不同进程中，通过进程间通信机制进行交互，使得文件系统各个元件之间相互隔离；33.模块m2：将代码根据文件系统语义分层化与模块化34.模块m3：修改musl-libc适配微内核的方式，使得动态链接libc的程序无需修改放入系统中使用；35.模块m4：采用惰性方式启动文件系统实例。36.优选地，在所述模块m1中：37.将文件系统拆分为用户态磁盘驱动服务、分区挂载服务、具体文件服务接口服务；38.在所述模块m2中：39.编写一个轻量级虚拟文件系统模块收纳所有文件系统请求，并处理这些请求中与具体文件系统制式无关的逻辑，以静态链接库形式提供给文件系统移植人员，移植方根据接口列表中要求的文件系统接口，以填空形式填入函数指针列表完成移植。40.优选地，在所述模块m3中：41.提供可移植操作系统接口兼容的接口，并以动态链接的形式交与应用程序调用，具体技术方法为：在现有的musl-libc源码中，扦插微内核完成文件系统逻辑的进程间通信逻辑，将之编译为一个gcc-wrapper与一个动态链接库libc.so，使得应用程序在动态链接与静态链接时均能够使用自定义的函数行为，并且这些函数保持了原有的可移植操作系统接口兼容性；42.针对需要内核参与的文件系统相关接口，在内核提供线程调度与内存管理相关接口时完整实现，具体细节如下：通过环形队列与拉取机制建立内核与用户态的异步通信机制，将内核中的缺页事件信息传递给用户态文件系统实例，文件系统实例通过读取该信息，通过调用内核提供的页表接口，进行用户态缺页处理；43.在所述模块m3中：44.当应用程序切实需要使用某个具体文件系统实例时，由全局的应用程序管理器加载具体的文件系统实例，当该文件系统实例已经在系统中运行时，直接建立应用程序与文件系统的通信通道。45.优选地，为了保证系统的隔离性，应用程序之间的文件系统状态应该相互隔离，包括两个无关进程之间不应该能通过文件系统访问到各自的进程状态，以及无关的请求之间不应该有性能影响；46.在可移植操作系统接口设计中，文件描述符由系统调用产生，随后通过一系列操作文件描述符的系统调用完成对文件系统的访问，文件描述符分为三类，一是文件类型的描述符，二是目录类型的描述符，三是其他描述符；在linux的设计中，由系统调用产生的描述符可能在不同进程之间共享偏移量数据，偏移量数据应当保存在文件系统服务端而非应用程序端。47.优选地，保存在应用程序侧的描述符信息，包括一个整型索引以及文件描述符的类型信息；保存在服务侧的entry，包含描述符偏移量信息；保存在服务侧的虚拟节点。48.文件描述符的索引由应用程序产生后发送给文件系统服务进行记录，文件系统服务侧会为每个描述符生成一个对应的entry，指向同一个文件的不同entry会被合并指向一个虚拟节点；文件系统服务侧，每个entry对应应用程序侧一个文件描述符，每个虚拟节点对应一个磁盘上的文件，而entry与虚拟节点之间是一个多对一的映射关系；49.应用程序以可移植操作系统接口兼容的接口使用文件系统，将调用转化成对应进程间通信的代码被封装到musl-libc中，有关文件描述符的数据结构被分到应用部分和服务侧部分，由应用和服务协同完成对文件描述符的操作，文件系统服务侧的数据结构根据应用程序的id分别保存，保证了不同应用进程之间的数据隔离和性能隔离；50.文件系统装饰器部分的功能主要是接收和分发进程间通信请求；文件系统通用模块位于装饰器和具体文件系统之间，作为可选模块；装饰器和具体文件系统封装成一个静态链接库，保留与具体文件系统有关的函数指针列表，由此最小化文件系统移植过程中的重复代码；51.每个文件系统实现都包含：一组文件系统装饰器和文件系统通用模块，一个文件系统实现。52.编码过程中如果开发人员需要扩展文件系统通用模块，则编写对应模块的代码并在文件系统通用模块部分进行对接；如果开发人员需要添加新的文件系统实现，则根据文件系统装饰器内的函数指针列表进行编写，以静态链接的方式与文件系统装饰器进行组合；该框架将文件系统共同的代码逻辑抽象为文件系统装饰器；53.执行过程中应用程序libc模块通过将用户的可移植操作系统接口请求转化成进程间通信形式发送给文件系统管理服务；文件系统管理服务根据路径参数惰性启动文件系统实例，不同的文件系统实例被分放在不同的进程中，以此达到隔离错误的目的；随后文件系统服务处理具体请求，件系统服务包括文件系统装饰器、文件系统通用模块、一个文件系统实现；文件系统服务进程内更新该请求对应的数据结构后，将运行结果信息返回给应用程序。54.与现有技术相比，本发明具有如下的有益效果：55.1、本发明通过分析现有微内核中文件系统的支持以及它们的不足之处，采用新的技术手段提出了全新的微内核文件系统架构；56.2、本发明为musl-libc与第三方文件系统库之间提供胶水层，使之适用于微内核，不仅使得系统应用程序在文件系统接口方面二进制兼容，并且拥有较好的可扩展性与安全特性；57.3、本发明适用于大多数微内核文件系统的开发场景，使得微内核文件系统功能的扩展更加高效便捷。附图说明58.通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：59.图1为数据结构的映射关系图；60.图2为文件系统框架代码结构；61.图3为控制流与数据流示意图。具体实施方式62.下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变化和改进。这些都属于本发明的保护范围。63.实施例1：64.本发明所提出的方法，主要解决以下问题：65.1.如何提供一个posix兼容的微内核虚拟文件系统？应用程序是否可以在不修改源代码的前提下移植到微内核上使用？66.2.如何高效的扩展与定制化微内核文件系统功能？67.3.如何利用微内核的进程间通信机制为文件系统组件提供隔离与容错特性？68.一种在微内核场景下的文件系统架构方案，包括：69.1.在微内核文件系统接口上实现二进制兼容，本发明通过修改musl-libc适配微内核的方式，使得动态链接libc的程序可以无需修改放入系统中使用，这意味着在linux的对应架构上编译出的二进制文件可以直接在新系统上运行；70.2.针对需要内核协作的文件系统功能，本发明提出了适用于多数场景的内核用户态交互逻辑与线程迁移模型，在该模型下可以实现跨进程的用户态缺页逻辑等；71.3.为了减少移植负担与重复代码，本发明提出将虚拟文件系统层以静态链接库的形式供给移植人员使用，移植人员只需根据具体文件系统制式以及被移植的第三方代码填写函数列表即可；72.4.为了实现容错并节约系统运行时资源，本发明提出采用惰性启动文件系统实例的方式，避免了一次启动全部实例导致的内存与cpu资源浪费，同时也提供了天然的容错恢复条件；73.5.本发明提出了一个完整的，适用于微内核上文件系统的场景的架构方案。74.本发明包含以下技术点，如图1-图3所示：75.1.利用进程隔离抽象，将文件系统实例放在不同进程中，通过进程间通信机制进行交互，使得文件系统各个元件之间相互隔离，具体技术方法为：将文件系统拆分为用户态磁盘驱动服务、分区挂载服务、具体文件服务接口服务；76.2.为了实现容错恢复机制，文件系统实例采用惰性启动的形式，具体为：当应用程序切实需要使用某个具体文件系统实例时，由全局的应用程序管理器来加载具体的文件系统实例，当该文件系统实例已经在系统中运行时，直接建立应用程序与文件系统的通信通道，这样一来既可以减少系统在运行时不必要的文件系统实例数量，又可以在实例意外退出之后由应用程序管理器恢复重启；77.3.为了用户程序的无修改迁移，我们的系统应当提供posix兼容的接口，并以动态链接的形式交与应用程序调用，具体技术方法为：在现有的musl-libc源码中，扦插微内核完成文件系统逻辑的进程间通信逻辑，将之编译为一个gcc-wrapper与一个动态链接库libc.so，使得应用程序在动态链接与静态链接时均可以使用我们自定义的函数行为，并且这些函数保持了原有的posix兼容性；78.4.针对需要内核参与的文件系统相关接口，例如mmap，在内核提供线程调度与内存管理相关接口时，可以完整实现，具体细节如下：通过环形队列与拉取(polling)机制建立内核与用户态的异步通信机制，将内核中的缺页事件信息传递给用户态文件系统实例，文件系统实例通过读取该信息，通过调用内核提供的页表接口，进行用户态缺页处理；79.5.为了使文件系统功能可以高效扩展，通过将代码根据文件系统语义分层化与模块化，最大的减小扩展功能的移植难度，具体细节如下：编写一个轻量级虚拟文件系统模块收纳所有文件系统请求，并处理这些请求中与具体文件系统制式无关的逻辑，将其以静态链接库形式提供给文件系统移植人员，移植方只需要根据接口列表中要求的少量文件系统接口，以填空形式填入函数指针列表即可完成移植。80.以下是对上述技术点的补充说明：81.由于文件系统是一个有状态的系统，例如文件描述符中的信息以及当前工作目录等，并且普遍的是一个一对多的模型，即一个文件系统实例需要服务于多个应用程序，如何切分这些状态以及在系统的何处保存这些状态成为了一个必须思考的问题。为了保证系统的隔离性，这些应用程序之间的文件系统状态应该相互隔离，这之中包括两个无关进程之间不应该能通过文件系统访问到各自的进程状态，以及无关的请求之间不应该有性能影响。82.在posix设计中，文件描述符由open等系统调用产生，随后通过一系列操作文件描述符的系统调用完成对文件系统的访问。文件描述符可以分为三类，一是文件类型的描述符，二是目录类型的描述符，三是其他描述符(包括管道、socket等)。文件与目录类型的描述符中比较关键的状态是偏移量，该偏移量保证了多次调用读操作读到连续的不同的片段。特别地，在linux的设计中，由fork等一些系统调用产生的描述符可能在不同进程之间共享偏移量数据，因而偏移量数据应当保存在文件系统服务端而非应用程序端。83.在本方案的具体设计中，包含以下几个关键的数据结构：保存在应用程序侧的描述符信息，通常包括一个整型索引以及文件描述符的类型信息；保存在服务侧的entry，包含描述符偏移量信息；保存在服务侧的虚拟节点。图1是运行时系统中这些数据结构的一种可能的映射关系：84.文件描述符的索引(整型的fd)由应用程序产生后发送给文件系统服务进行记录，文件系统服务侧会为每个描述符生成一个对应的entry，指向同一个文件的不同entry会被合并指向一个虚拟节点(vnode)。换句话说，文件系统服务侧，每个entry对应应用程序侧一个文件描述符，每个虚拟节点对应一个磁盘上的文件，而entry与虚拟节点之间是一个多对一的映射关系。85.在该实现下，应用程序可以以posix兼容的接口使用文件系统，将调用转化成对应进程间通信的代码被封装到musl-libc中，有关文件描述符的数据结构被分到应用部分和服务侧部分，由应用和服务协同完成对文件描述符的操作。特别的，文件系统服务侧的数据结构根据应用程序的id分别保存，从而保证了不同应用进程之间的数据隔离和性能隔离。86.本方案另外提出了有关代码结构的一些建议条目，以最大化文件系统框架的可扩展性与易使用性。解决办法如图2所示：87.文件系统装饰器部分的功能主要是接收和分发进程间通信请求；文件系统通用模块例如页缓存等位于装饰器和具体文件系统之间，作为可选模块。上述两者可以封装成一个静态链接库，仅保留与具体文件系统有关的函数指针列表，由此最小化文件系统移植过程中的重复代码。88.每个文件系统实现都包含：一组文件系统装饰器和文件系统通用模块，一个文件系统实现(文件系统1或者文件系统2等)。89.编码过程中：如果开发人员需要扩展文件系统通用模块，则编写对应模块的代码并在“文件系统通用模块”部分进行对接；如果开发人员需要添加新的文件系统实现，则根据文件系统装饰器内的函数指针列表进行编写，以静态链接的方式与文件系统装饰器进行组合。该框架将大部分文件系统共同的代码逻辑抽象为文件系统装饰器，以此提高代码重用率，减少重复代码的编写。例如装饰器中的函数指针列表以及通用模块中的页缓存扩展，都是不同文件系统之间可以共用的代码。90.执行过程中：应用程序libc模块通过将用户的posix请求转化成进程间通信形式发送给文件系统管理服务；文件系统管理服务根据路径参数惰性启动文件系统实例，不同的文件系统实例被分放在不同的进程中，以此达到隔离错误的目的；随后文件系统服务(包括文件系统装饰器、文件系统通用模块、一个文件系统实现)处理具体请求；文件系统服务进程内更新该请求对应的数据结构(entry、vnode等)后，将运行结果信息返回给应用程序。91.技术数据解释：[0092]-fs：filesystem，文件系统[0093]-mmio：memory-mappedi/o，内存映射i/o[0094]-spdk：storageperformancedevelopmentkit，存储性能开发工具[0095]-posix：portableoperationsysteminterface，可移植操作系统接口[0096]实施例2：[0097]实施例2为实施例1的优选例，以更为具体地对本发明进行说明。[0098]下面针对一个具体的文件系统请求(openat)举例我们架构中的控制流和数据流是怎么工作的。[0099]一个openat请求的语义是，通过给定路径，当路径合法对应一个目录项时，打开一个对应的文件描述符，之后可以通过这个文件描述符来访问和修改这个文件的内容。[0100]在本方案的框架中，一个openat请求涉及到三个文件系统组件：文件系统管理服务、文件系统服务、应用程序。请求首先由客户端出发将路径通过进程间通信发送给文件系统管理服务，文件系统管理服务根据路径解析出路径所对应的文件系统服务实例，然后将对应的capability发送回请求方，请求方再通过这个capability与对应的文件系统服务建立连接；文件系统服务侧会访问磁盘数据结构，找到对应的目录项，如果打开成功，则会在文件系统服务中创建一些相关的数据结构，并通过进程间通信返回请求状态。[0101]对于mmap这个特殊的posix调用，它的处理流程如下：[0102]1.应用程序调用mmap接口，在内核中注册一块物理内存区域标记为mmap使用，携带内存相关参数发送进程间通信到文件系统服务；[0103]2.文件系统服务根据参数内容为其绑定一个缺页处理函数；[0104]3.返回应用程序执行其他代码，并通过访存操作触发缺页；[0105]4.缺页使得线程下陷至内核，内核找到对应的内存区域，并将代码切换到文件系统服务内的缺页处理函数中，以此实现用户态缺页处理；[0106]5.缺页处理完成后返回触发缺页的代码并继续执行。[0107]至此，我们已经分别介绍了框架是如何处理一般的和特殊的posix接口的兼容的。[0108]本领域技术人员知道，除了以纯计算机可读程序代码方式实现本发明提供的系统、装置及其各个模块以外，完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统、装置及其各个模块以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同程序。所以，本发明提供的系统、装置及其各个模块可以被认为是一种硬件部件，而对其内包括的用于实现各种程序的模块也可以视为硬件部件内的结构；也可以将用于实现各种功能的模块视为既可以是实现方法的软件程序又可以是硬件部件内的结构。[0109]以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变化或修改，这并不影响本发明的实质内容。在不冲突的情况下，本技术的实施例和实施例中的特征可以任意相互组合。当前第1页12当前第1页12
技术领域：
：，具体地，涉及一种面向微内核架构的虚拟文件构建方法及系统。
背景技术：
：：2.文件系统(fs)是计算机硬件软件桥梁之一，它将硬盘上存储的数据结构，以文件和目录的形式转化为软件抽象，供应用程序使用。文件系统通过提供一系列标准的操作文件和目录的接口，使包含有持久化需求的应用便捷地实现持久化支持。在传统的宏内核以及混合内核架构下，文件系统本身处于内核态，通过文件相关的系统调用下陷于内核完成文件操作。而微内核场景下，内核部分只负责最基础的操作系统模块，这些模块主要是：内存管理、线程调度、进程间通信。而其他的系统组件，包括文件系统，都将在用户态进程中实现。文件系统本身也依赖于其他众多的系统组件服务，包括磁盘驱动器等。将文件系统本身放在用户空间也会使整个系统内的软件架构以及依赖关系变得更为复杂，除此之外，隔离和容错也将成为新的挑战。3.随着操作系统工业与学术成果的交织，越来越多的工业微内核步入人们的视野。微内核架构与为人熟知的宏内核架构有以下一些明显的区别。顾名思义，微内核架构中，内核空间的工作相对较轻，原先在宏内核架构中的功能都将上移至用户空间。其次，微内核的交互模型与宏内核也有明显的差别，由于很多功能被放在用户空间，应用程序为了获取特定的操作系统服务功能，必须通过进程间通信的方式，而非宏内核通过系统调用下陷内核后返回的模式。其三，随着微内核架构相比宏内核架构将内核模块功能上提至用户态，使得微内核的内核部分相比宏内核缺少了更多的语义，例如微内核的内核部分没有文件系统，也就没有文件描述符等等语义和结构。微内核相比宏内核有很多独到的优势：一者，由于内核职责单一，大多数对于系统功能的扩展都会以应用程序的形式被实现在系统中，这对于动态扩展系统功能以及热更新等特性带来了很多便捷；二者，当系统中出现不可预见的错误，这些错误往往会被隔离在一个或几个应用程序之中，而不会导致整个系统的崩溃，这为实现容错以及隔离特性带来了先天的优势。4.微内核的一个重要特点在于系统在获取系统服务的时候，相比宏内核要多若干个进程间通信，而这些进程间通信会导致一个功能的响应时间变长。而当前很多学术工作针对进程间通信做出优化，使得单次微内核的进程间通信耗时约几百时钟周期，相较于应用逻辑本身的开销，进程间通信的开销不再成为瓶颈，从而让微内核提供更多的系统特性的同时保证与宏内核相近的性能。5.文件系统方面，研究界与工业界有不少相关工作在微内核场景下为应用程序提供用户态文件系统功能支持。其中用户态的驱动程序是一个主要部分，使用用户态库越过内核访问存储设备是其中一种方式，例如通过spdk与nvme设备交互。另外，一些通过mmio与设备交互的驱动程序也可以直接将其解耦放入用户态，使其在用户态完成驱动的主要功能，例如emmc驱动与sd卡设备交互。另一个方面则是系统架构和接口方面，市面上的微内核，一些使用的是类似宏内核的聚合式设计，一些则是采用另行设计的单机分布式架构，而这些无一例外提供的均是系统特有的接口，这意味着用户程序需要使用这些接口重写才能在该系统上运行。6.专利文献cn112698918a(申请号：cn202110013164.8)公开了一种基于构建环境的虚拟机文件生成方法、装置。该方法包括：采集搭建的构建环境所需要的软硬件配置和软件依赖；根据所述软硬件配置和所述软件依赖生成预设格式的配置文件；创建虚拟机，并根据所述配置文件中的软硬件配置信息及软件依赖信息在所述虚拟机中创建与所述软硬件配置信息及所述软件依赖信息相对应的虚拟机硬件与虚拟机软件；在所述虚拟机中完成所述虚拟机硬件与虚拟机软件的创建后，对包含所述虚拟机硬件与虚拟机软件的虚拟机进行保存，以生成虚拟机文件。但该发明没有为musl-libc与第三方文件系统库之间提供胶水层，使之适用于微内核。技术实现要素：7.针对现有技术中的缺陷，本发明的目的是提供一种面向微内核架构的虚拟文件构建方法及系统。8.根据本发明提供的一种面向微内核架构的虚拟文件构建方法，包括：9.步骤s1：利用进程隔离抽象，将文件系统实例放在不同进程中，通过进程间通信机制进行交互，使得文件系统各个元件之间相互隔离；10.步骤s2：将代码根据文件系统语义分层化与模块化11.步骤s3：修改musl-libc适配微内核的方式，使得动态链接libc的程序无需修改放入系统中使用；12.步骤s4：采用惰性方式启动文件系统实例。13.优选地，在所述步骤s1中：14.将文件系统拆分为用户态磁盘驱动服务、分区挂载服务、具体文件服务接口服务；15.在所述步骤s2中：16.编写一个轻量级虚拟文件系统模块收纳所有文件系统请求，并处理这些请求中与具体文件系统制式无关的逻辑，以静态链接库形式提供给文件系统移植人员，移植方根据接口列表中要求的文件系统接口，以填空形式填入函数指针列表完成移植。17.优选地，在所述步骤s3中：18.提供可移植操作系统接口兼容的接口，并以动态链接的形式交与应用程序调用，具体技术方法为：在现有的musl-libc源码中，扦插微内核完成文件系统逻辑的进程间通信逻辑，将之编译为一个gcc-wrapper与一个动态链接库libc.so，使得应用程序在动态链接与静态链接时均能够使用自定义的函数行为，并且这些函数保持了原有的可移植操作系统接口兼容性；19.针对需要内核参与的文件系统相关接口，在内核提供线程调度与内存管理相关接口时完整实现，具体细节如下：通过环形队列与拉取机制建立内核与用户态的异步通信机制，将内核中的缺页事件信息传递给用户态文件系统实例，文件系统实例通过读取该信息，通过调用内核提供的页表接口，进行用户态缺页处理；20.在所述步骤s3中：21.当应用程序切实需要使用某个具体文件系统实例时，由全局的应用程序管理器加载具体的文件系统实例，当该文件系统实例已经在系统中运行时，直接建立应用程序与文件系统的通信通道。22.优选地，为了保证系统的隔离性，应用程序之间的文件系统状态应该相互隔离，包括两个无关进程之间不应该能通过文件系统访问到各自的进程状态，以及无关的请求之间不应该有性能影响；23.在可移植操作系统接口设计中，文件描述符由系统调用产生，随后通过一系列操作文件描述符的系统调用完成对文件系统的访问，文件描述符分为三类，一是文件类型的描述符，二是目录类型的描述符，三是其他描述符；在linux的设计中，由系统调用产生的描述符可能在不同进程之间共享偏移量数据，偏移量数据应当保存在文件系统服务端而非应用程序端。24.优选地，保存在应用程序侧的描述符信息，包括一个整型索引以及文件描述符的类型信息；保存在服务侧的entry，包含描述符偏移量信息；保存在服务侧的虚拟节点。25.文件描述符的索引由应用程序产生后发送给文件系统服务进行记录，文件系统服务侧会为每个描述符生成一个对应的entry，指向同一个文件的不同entry会被合并指向一个虚拟节点；文件系统服务侧，每个entry对应应用程序侧一个文件描述符，每个虚拟节点对应一个磁盘上的文件，而entry与虚拟节点之间是一个多对一的映射关系；26.应用程序以可移植操作系统接口兼容的接口使用文件系统，将调用转化成对应进程间通信的代码被封装到musl-libc中，有关文件描述符的数据结构被分到应用部分和服务侧部分，由应用和服务协同完成对文件描述符的操作，文件系统服务侧的数据结构根据应用程序的id分别保存，保证了不同应用进程之间的数据隔离和性能隔离；27.文件系统装饰器部分的功能主要是接收和分发进程间通信请求；文件系统通用模块位于装饰器和具体文件系统之间，作为可选模块；装饰器和具体文件系统封装成一个静态链接库，保留与具体文件系统有关的函数指针列表，由此最小化文件系统移植过程中的重复代码；28.每个文件系统实现都包含：一组文件系统装饰器和文件系统通用模块，一个文件系统实现。29.编码过程中如果开发人员需要扩展文件系统通用模块，则编写对应模块的代码并在文件系统通用模块部分进行对接；如果开发人员需要添加新的文件系统实现，则根据文件系统装饰器内的函数指针列表进行编写，以静态链接的方式与文件系统装饰器进行组合；该框架将文件系统共同的代码逻辑抽象为文件系统装饰器；30.执行过程中应用程序libc模块通过将用户的可移植操作系统接口请求转化成进程间通信形式发送给文件系统管理服务；文件系统管理服务根据路径参数惰性启动文件系统实例，不同的文件系统实例被分放在不同的进程中，以此达到隔离错误的目的；随后文件系统服务处理具体请求，件系统服务包括文件系统装饰器、文件系统通用模块、一个文件系统实现；文件系统服务进程内更新该请求对应的数据结构后，将运行结果信息返回给应用程序。31.根据本发明提供的一种面向微内核架构的虚拟文件构建系统，包括：32.模块m1：利用进程隔离抽象，将文件系统实例放在不同进程中，通过进程间通信机制进行交互，使得文件系统各个元件之间相互隔离；33.模块m2：将代码根据文件系统语义分层化与模块化34.模块m3：修改musl-libc适配微内核的方式，使得动态链接libc的程序无需修改放入系统中使用；35.模块m4：采用惰性方式启动文件系统实例。36.优选地，在所述模块m1中：37.将文件系统拆分为用户态磁盘驱动服务、分区挂载服务、具体文件服务接口服务；38.在所述模块m2中：39.编写一个轻量级虚拟文件系统模块收纳所有文件系统请求，并处理这些请求中与具体文件系统制式无关的逻辑，以静态链接库形式提供给文件系统移植人员，移植方根据接口列表中要求的文件系统接口，以填空形式填入函数指针列表完成移植。40.优选地，在所述模块m3中：41.提供可移植操作系统接口兼容的接口，并以动态链接的形式交与应用程序调用，具体技术方法为：在现有的musl-libc源码中，扦插微内核完成文件系统逻辑的进程间通信逻辑，将之编译为一个gcc-wrapper与一个动态链接库libc.so，使得应用程序在动态链接与静态链接时均能够使用自定义的函数行为，并且这些函数保持了原有的可移植操作系统接口兼容性；42.针对需要内核参与的文件系统相关接口，在内核提供线程调度与内存管理相关接口时完整实现，具体细节如下：通过环形队列与拉取机制建立内核与用户态的异步通信机制，将内核中的缺页事件信息传递给用户态文件系统实例，文件系统实例通过读取该信息，通过调用内核提供的页表接口，进行用户态缺页处理；43.在所述模块m3中：44.当应用程序切实需要使用某个具体文件系统实例时，由全局的应用程序管理器加载具体的文件系统实例，当该文件系统实例已经在系统中运行时，直接建立应用程序与文件系统的通信通道。45.优选地，为了保证系统的隔离性，应用程序之间的文件系统状态应该相互隔离，包括两个无关进程之间不应该能通过文件系统访问到各自的进程状态，以及无关的请求之间不应该有性能影响；46.在可移植操作系统接口设计中，文件描述符由系统调用产生，随后通过一系列操作文件描述符的系统调用完成对文件系统的访问，文件描述符分为三类，一是文件类型的描述符，二是目录类型的描述符，三是其他描述符；在linux的设计中，由系统调用产生的描述符可能在不同进程之间共享偏移量数据，偏移量数据应当保存在文件系统服务端而非应用程序端。47.优选地，保存在应用程序侧的描述符信息，包括一个整型索引以及文件描述符的类型信息；保存在服务侧的entry，包含描述符偏移量信息；保存在服务侧的虚拟节点。48.文件描述符的索引由应用程序产生后发送给文件系统服务进行记录，文件系统服务侧会为每个描述符生成一个对应的entry，指向同一个文件的不同entry会被合并指向一个虚拟节点；文件系统服务侧，每个entry对应应用程序侧一个文件描述符，每个虚拟节点对应一个磁盘上的文件，而entry与虚拟节点之间是一个多对一的映射关系；49.应用程序以可移植操作系统接口兼容的接口使用文件系统，将调用转化成对应进程间通信的代码被封装到musl-libc中，有关文件描述符的数据结构被分到应用部分和服务侧部分，由应用和服务协同完成对文件描述符的操作，文件系统服务侧的数据结构根据应用程序的id分别保存，保证了不同应用进程之间的数据隔离和性能隔离；50.文件系统装饰器部分的功能主要是接收和分发进程间通信请求；文件系统通用模块位于装饰器和具体文件系统之间，作为可选模块；装饰器和具体文件系统封装成一个静态链接库，保留与具体文件系统有关的函数指针列表，由此最小化文件系统移植过程中的重复代码；51.每个文件系统实现都包含：一组文件系统装饰器和文件系统通用模块，一个文件系统实现。52.编码过程中如果开发人员需要扩展文件系统通用模块，则编写对应模块的代码并在文件系统通用模块部分进行对接；如果开发人员需要添加新的文件系统实现，则根据文件系统装饰器内的函数指针列表进行编写，以静态链接的方式与文件系统装饰器进行组合；该框架将文件系统共同的代码逻辑抽象为文件系统装饰器；53.执行过程中应用程序libc模块通过将用户的可移植操作系统接口请求转化成进程间通信形式发送给文件系统管理服务；文件系统管理服务根据路径参数惰性启动文件系统实例，不同的文件系统实例被分放在不同的进程中，以此达到隔离错误的目的；随后文件系统服务处理具体请求，件系统服务包括文件系统装饰器、文件系统通用模块、一个文件系统实现；文件系统服务进程内更新该请求对应的数据结构后，将运行结果信息返回给应用程序。54.与现有技术相比，本发明具有如下的有益效果：55.1、本发明通过分析现有微内核中文件系统的支持以及它们的不足之处，采用新的技术手段提出了全新的微内核文件系统架构；56.2、本发明为musl-libc与第三方文件系统库之间提供胶水层，使之适用于微内核，不仅使得系统应用程序在文件系统接口方面二进制兼容，并且拥有较好的可扩展性与安全特性；57.3、本发明适用于大多数微内核文件系统的开发场景，使得微内核文件系统功能的扩展更加高效便捷。附图说明58.通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：59.图1为数据结构的映射关系图；60.图2为文件系统框架代码结构；61.图3为控制流与数据流示意图。具体实施方式62.下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变化和改进。这些都属于本发明的保护范围。63.实施例1：64.本发明所提出的方法，主要解决以下问题：65.1.如何提供一个posix兼容的微内核虚拟文件系统？应用程序是否可以在不修改源代码的前提下移植到微内核上使用？66.2.如何高效的扩展与定制化微内核文件系统功能？67.3.如何利用微内核的进程间通信机制为文件系统组件提供隔离与容错特性？68.一种在微内核场景下的文件系统架构方案，包括：69.1.在微内核文件系统接口上实现二进制兼容，本发明通过修改musl-libc适配微内核的方式，使得动态链接libc的程序可以无需修改放入系统中使用，这意味着在linux的对应架构上编译出的二进制文件可以直接在新系统上运行；70.2.针对需要内核协作的文件系统功能，本发明提出了适用于多数场景的内核用户态交互逻辑与线程迁移模型，在该模型下可以实现跨进程的用户态缺页逻辑等；71.3.为了减少移植负担与重复代码，本发明提出将虚拟文件系统层以静态链接库的形式供给移植人员使用，移植人员只需根据具体文件系统制式以及被移植的第三方代码填写函数列表即可；72.4.为了实现容错并节约系统运行时资源，本发明提出采用惰性启动文件系统实例的方式，避免了一次启动全部实例导致的内存与cpu资源浪费，同时也提供了天然的容错恢复条件；73.5.本发明提出了一个完整的，适用于微内核上文件系统的场景的架构方案。74.本发明包含以下技术点，如图1-图3所示：75.1.利用进程隔离抽象，将文件系统实例放在不同进程中，通过进程间通信机制进行交互，使得文件系统各个元件之间相互隔离，具体技术方法为：将文件系统拆分为用户态磁盘驱动服务、分区挂载服务、具体文件服务接口服务；76.2.为了实现容错恢复机制，文件系统实例采用惰性启动的形式，具体为：当应用程序切实需要使用某个具体文件系统实例时，由全局的应用程序管理器来加载具体的文件系统实例，当该文件系统实例已经在系统中运行时，直接建立应用程序与文件系统的通信通道，这样一来既可以减少系统在运行时不必要的文件系统实例数量，又可以在实例意外退出之后由应用程序管理器恢复重启；77.3.为了用户程序的无修改迁移，我们的系统应当提供posix兼容的接口，并以动态链接的形式交与应用程序调用，具体技术方法为：在现有的musl-libc源码中，扦插微内核完成文件系统逻辑的进程间通信逻辑，将之编译为一个gcc-wrapper与一个动态链接库libc.so，使得应用程序在动态链接与静态链接时均可以使用我们自定义的函数行为，并且这些函数保持了原有的posix兼容性；78.4.针对需要内核参与的文件系统相关接口，例如mmap，在内核提供线程调度与内存管理相关接口时，可以完整实现，具体细节如下：通过环形队列与拉取(polling)机制建立内核与用户态的异步通信机制，将内核中的缺页事件信息传递给用户态文件系统实例，文件系统实例通过读取该信息，通过调用内核提供的页表接口，进行用户态缺页处理；79.5.为了使文件系统功能可以高效扩展，通过将代码根据文件系统语义分层化与模块化，最大的减小扩展功能的移植难度，具体细节如下：编写一个轻量级虚拟文件系统模块收纳所有文件系统请求，并处理这些请求中与具体文件系统制式无关的逻辑，将其以静态链接库形式提供给文件系统移植人员，移植方只需要根据接口列表中要求的少量文件系统接口，以填空形式填入函数指针列表即可完成移植。80.以下是对上述技术点的补充说明：81.由于文件系统是一个有状态的系统，例如文件描述符中的信息以及当前工作目录等，并且普遍的是一个一对多的模型，即一个文件系统实例需要服务于多个应用程序，如何切分这些状态以及在系统的何处保存这些状态成为了一个必须思考的问题。为了保证系统的隔离性，这些应用程序之间的文件系统状态应该相互隔离，这之中包括两个无关进程之间不应该能通过文件系统访问到各自的进程状态，以及无关的请求之间不应该有性能影响。82.在posix设计中，文件描述符由open等系统调用产生，随后通过一系列操作文件描述符的系统调用完成对文件系统的访问。文件描述符可以分为三类，一是文件类型的描述符，二是目录类型的描述符，三是其他描述符(包括管道、socket等)。文件与目录类型的描述符中比较关键的状态是偏移量，该偏移量保证了多次调用读操作读到连续的不同的片段。特别地，在linux的设计中，由fork等一些系统调用产生的描述符可能在不同进程之间共享偏移量数据，因而偏移量数据应当保存在文件系统服务端而非应用程序端。83.在本方案的具体设计中，包含以下几个关键的数据结构：保存在应用程序侧的描述符信息，通常包括一个整型索引以及文件描述符的类型信息；保存在服务侧的entry，包含描述符偏移量信息；保存在服务侧的虚拟节点。图1是运行时系统中这些数据结构的一种可能的映射关系：84.文件描述符的索引(整型的fd)由应用程序产生后发送给文件系统服务进行记录，文件系统服务侧会为每个描述符生成一个对应的entry，指向同一个文件的不同entry会被合并指向一个虚拟节点(vnode)。换句话说，文件系统服务侧，每个entry对应应用程序侧一个文件描述符，每个虚拟节点对应一个磁盘上的文件，而entry与虚拟节点之间是一个多对一的映射关系。85.在该实现下，应用程序可以以posix兼容的接口使用文件系统，将调用转化成对应进程间通信的代码被封装到musl-libc中，有关文件描述符的数据结构被分到应用部分和服务侧部分，由应用和服务协同完成对文件描述符的操作。特别的，文件系统服务侧的数据结构根据应用程序的id分别保存，从而保证了不同应用进程之间的数据隔离和性能隔离。86.本方案另外提出了有关代码结构的一些建议条目，以最大化文件系统框架的可扩展性与易使用性。解决办法如图2所示：87.文件系统装饰器部分的功能主要是接收和分发进程间通信请求；文件系统通用模块例如页缓存等位于装饰器和具体文件系统之间，作为可选模块。上述两者可以封装成一个静态链接库，仅保留与具体文件系统有关的函数指针列表，由此最小化文件系统移植过程中的重复代码。88.每个文件系统实现都包含：一组文件系统装饰器和文件系统通用模块，一个文件系统实现(文件系统1或者文件系统2等)。89.编码过程中：如果开发人员需要扩展文件系统通用模块，则编写对应模块的代码并在“文件系统通用模块”部分进行对接；如果开发人员需要添加新的文件系统实现，则根据文件系统装饰器内的函数指针列表进行编写，以静态链接的方式与文件系统装饰器进行组合。该框架将大部分文件系统共同的代码逻辑抽象为文件系统装饰器，以此提高代码重用率，减少重复代码的编写。例如装饰器中的函数指针列表以及通用模块中的页缓存扩展，都是不同文件系统之间可以共用的代码。90.执行过程中：应用程序libc模块通过将用户的posix请求转化成进程间通信形式发送给文件系统管理服务；文件系统管理服务根据路径参数惰性启动文件系统实例，不同的文件系统实例被分放在不同的进程中，以此达到隔离错误的目的；随后文件系统服务(包括文件系统装饰器、文件系统通用模块、一个文件系统实现)处理具体请求；文件系统服务进程内更新该请求对应的数据结构(entry、vnode等)后，将运行结果信息返回给应用程序。91.技术数据解释：[0092]-fs：filesystem，文件系统[0093]-mmio：memory-mappedi/o，内存映射i/o[0094]-spdk：storageperformancedevelopmentkit，存储性能开发工具[0095]-posix：portableoperationsysteminterface，可移植操作系统接口[0096]实施例2：[0097]实施例2为实施例1的优选例，以更为具体地对本发明进行说明。[0098]下面针对一个具体的文件系统请求(openat)举例我们架构中的控制流和数据流是怎么工作的。[0099]一个openat请求的语义是，通过给定路径，当路径合法对应一个目录项时，打开一个对应的文件描述符，之后可以通过这个文件描述符来访问和修改这个文件的内容。[0100]在本方案的框架中，一个openat请求涉及到三个文件系统组件：文件系统管理服务、文件系统服务、应用程序。请求首先由客户端出发将路径通过进程间通信发送给文件系统管理服务，文件系统管理服务根据路径解析出路径所对应的文件系统服务实例，然后将对应的capability发送回请求方，请求方再通过这个capability与对应的文件系统服务建立连接；文件系统服务侧会访问磁盘数据结构，找到对应的目录项，如果打开成功，则会在文件系统服务中创建一些相关的数据结构，并通过进程间通信返回请求状态。[0101]对于mmap这个特殊的posix调用，它的处理流程如下：[0102]1.应用程序调用mmap接口，在内核中注册一块物理内存区域标记为mmap使用，携带内存相关参数发送进程间通信到文件系统服务；[0103]2.文件系统服务根据参数内容为其绑定一个缺页处理函数；[0104]3.返回应用程序执行其他代码，并通过访存操作触发缺页；[0105]4.缺页使得线程下陷至内核，内核找到对应的内存区域，并将代码切换到文件系统服务内的缺页处理函数中，以此实现用户态缺页处理；[0106]5.缺页处理完成后返回触发缺页的代码并继续执行。[0107]至此，我们已经分别介绍了框架是如何处理一般的和特殊的posix接口的兼容的。[0108]本领域技术人员知道，除了以纯计算机可读程序代码方式实现本发明提供的系统、装置及其各个模块以外，完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统、装置及其各个模块以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同程序。所以，本发明提供的系统、装置及其各个模块可以被认为是一种硬件部件，而对其内包括的用于实现各种程序的模块也可以视为硬件部件内的结构；也可以将用于实现各种功能的模块视为既可以是实现方法的软件程序又可以是硬件部件内的结构。[0109]以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变化或修改，这并不影响本发明的实质内容。在不冲突的情况下，本技术的实施例和实施例中的特征可以任意相互组合。当前第1页12当前第1页12
再多了解一些
本文用于创业者技术爱好者查询，仅供学习研究，如用于商业用途，请联系技术所有人。
