面向微内核架构的虚拟文件构建方法及系统技术方案

本发明专利技术提供了一种面向微内核架构的虚拟文件构建方法及系统，包括：步骤S1：利用进程隔离抽象，将文件系统实例放在不同进程中，通过进程间通信机制进行交互，使得文件系统各个元件之间相互隔离；步骤S2：将代码根据文件系统语义分层化与模块化步骤S3：修改musl

【技术实现步骤摘要】
面向微内核架构的虚拟文件构建方法及系统


[0001]本专利技术涉及虚拟机
，具体地，涉及一种面向微内核架构的虚拟文件构建方法及系统。

技术介绍

[0002]文件系统(FS)是计算机硬件软件桥梁之一，它将硬盘上存储的数据结构，以文件和目录的形式转化为软件抽象，供应用程序使用。文件系统通过提供一系列标准的操作文件和目录的接口，使包含有持久化需求的应用便捷地实现持久化支持。在传统的宏内核以及混合内核架构下，文件系统本身处于内核态，通过文件相关的系统调用下陷于内核完成文件操作。而微内核场景下，内核部分只负责最基础的操作系统模块，这些模块主要是：内存管理、线程调度、进程间通信。而其他的系统组件，包括文件系统，都将在用户态进程中实现。文件系统本身也依赖于其他众多的系统组件服务，包括磁盘驱动器等。将文件系统本身放在用户空间也会使整个系统内的软件架构以及依赖关系变得更为复杂，除此之外，隔离和容错也将成为新的挑战。
[0003]随着操作系统工业与学术成果的交织，越来越多的工业微内核步入人们的视野。微内核架构与为人熟知的宏内核架构有以下一些明显的区别。顾名思义，微内核架构中，内核空间的工作相对较轻，原先在宏内核架构中的功能都将上移至用户空间。其次，微内核的交互模型与宏内核也有明显的差别，由于很多功能被放在用户空间，应用程序为了获取特定的操作系统服务功能，必须通过进程间通信的方式，而非宏内核通过系统调用下陷内核后返回的模式。其三，随着微内核架构相比宏内核架构将内核模块功能上提至用户态，使得微内核的内核部分相比宏内核缺少了更多的语义，例如微内核的内核部分没有文件系统，也就没有文件描述符等等语义和结构。微内核相比宏内核有很多独到的优势：一者，由于内核职责单一，大多数对于系统功能的扩展都会以应用程序的形式被实现在系统中，这对于动态扩展系统功能以及热更新等特性带来了很多便捷；二者，当系统中出现不可预见的错误，这些错误往往会被隔离在一个或几个应用程序之中，而不会导致整个系统的崩溃，这为实现容错以及隔离特性带来了先天的优势。
[0004]微内核的一个重要特点在于系统在获取系统服务的时候，相比宏内核要多若干个进程间通信，而这些进程间通信会导致一个功能的响应时间变长。而当前很多学术工作针对进程间通信做出优化，使得单次微内核的进程间通信耗时约几百时钟周期，相较于应用逻辑本身的开销，进程间通信的开销不再成为瓶颈，从而让微内核提供更多的系统特性的同时保证与宏内核相近的性能。
[0005]文件系统方面，研究界与工业界有不少相关工作在微内核场景下为应用程序提供用户态文件系统功能支持。其中用户态的驱动程序是一个主要部分，使用用户态库越过内核访问存储设备是其中一种方式，例如通过SPDK与NVMe设备交互。另外，一些通过MMIO与设备交互的驱动程序也可以直接将其解耦放入用户态，使其在用户态完成驱动的主要功能，例如eMMC驱动与sd卡设备交互。另一个方面则是系统架构和接口方面，市面上的微内核，一
些使用的是类似宏内核的聚合式设计，一些则是采用另行设计的单机分布式架构，而这些无一例外提供的均是系统特有的接口，这意味着用户程序需要使用这些接口重写才能在该系统上运行。
[0006]专利文献CN112698918A(申请号：CN202110013164.8)公开了一种基于构建环境的虚拟机文件生成方法、装置。该方法包括：采集搭建的构建环境所需要的软硬件配置和软件依赖；根据所述软硬件配置和所述软件依赖生成预设格式的配置文件；创建虚拟机，并根据所述配置文件中的软硬件配置信息及软件依赖信息在所述虚拟机中创建与所述软硬件配置信息及所述软件依赖信息相对应的虚拟机硬件与虚拟机软件；在所述虚拟机中完成所述虚拟机硬件与虚拟机软件的创建后，对包含所述虚拟机硬件与虚拟机软件的虚拟机进行保存，以生成虚拟机文件。但该专利技术没有为musl
‑
libc与第三方文件系统库之间提供胶水层，使之适用于微内核。

技术实现思路

[0007]针对现有技术中的缺陷，本专利技术的目的是提供一种面向微内核架构的虚拟文件构建方法及系统。
[0008]根据本专利技术提供的一种面向微内核架构的虚拟文件构建方法，包括：
[0009]步骤S1：利用进程隔离抽象，将文件系统实例放在不同进程中，通过进程间通信机制进行交互，使得文件系统各个元件之间相互隔离；
[0010]步骤S2：将代码根据文件系统语义分层化与模块化
[0011]步骤S3：修改musl
‑
libc适配微内核的方式，使得动态链接libc的程序无需修改放入系统中使用；
[0012]步骤S4：采用惰性方式启动文件系统实例。
[0013]优选地，在所述步骤S1中：
[0014]将文件系统拆分为用户态磁盘驱动服务、分区挂载服务、具体文件服务接口服务；
[0015]在所述步骤S2中：
[0016]编写一个轻量级虚拟文件系统模块收纳所有文件系统请求，并处理这些请求中与具体文件系统制式无关的逻辑，以静态链接库形式提供给文件系统移植人员，移植方根据接口列表中要求的文件系统接口，以填空形式填入函数指针列表完成移植。
[0017]优选地，在所述步骤S3中：
[0018]提供可移植操作系统接口兼容的接口，并以动态链接的形式交与应用程序调用，具体技术方法为：在现有的musl
‑
libc源码中，扦插微内核完成文件系统逻辑的进程间通信逻辑，将之编译为一个gcc
‑
wrapper与一个动态链接库libc.so，使得应用程序在动态链接与静态链接时均能够使用自定义的函数行为，并且这些函数保持了原有的可移植操作系统接口兼容性；
[0019]针对需要内核参与的文件系统相关接口，在内核提供线程调度与内存管理相关接口时完整实现，具体细节如下：通过环形队列与拉取机制建立内核与用户态的异步通信机制，将内核中的缺页事件信息传递给用户态文件系统实例，文件系统实例通过读取该信息，通过调用内核提供的页表接口，进行用户态缺页处理；
[0020]在所述步骤S3中：
[0021]当应用程序切实需要使用某个具体文件系统实例时，由全局的应用程序管理器加载具体的文件系统实例，当该文件系统实例已经在系统中运行时，直接建立应用程序与文件系统的通信通道。
[0022]优选地，为了保证系统的隔离性，应用程序之间的文件系统状态应该相互隔离，包括两个无关进程之间不应该能通过文件系统访问到各自的进程状态，以及无关的请求之间不应该有性能影响；
[0023]在可移植操作系统接口设计中，文件描述符由系统调用产生，随后通过一系列操作文件描述符的系统调用完成对文件系统的访问，文件描述符分为三类，一是文件类型的描述符，二是目录类型的描述符，三是其他描述符；在Linux的设计中，由系统调用产生的描述符可能在不同进程之间共享偏移量数据，偏移量数据应当保存在文件系统服务端而非应用程序端。
[0024]优选地，保存在应用程序侧的描述符信息，包括一个整型索引本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种面向微内核架构的虚拟文件构建方法，其特征在于，包括：步骤S1：利用进程隔离抽象，将文件系统实例放在不同进程中，通过进程间通信机制进行交互，使得文件系统各个元件之间相互隔离；步骤S2：将代码根据文件系统语义分层化与模块化步骤S3：修改musl
‑
libc适配微内核的方式，使得动态链接libc的程序无需修改放入系统中使用；步骤S4：采用惰性方式启动文件系统实例。2.根据权利要求1所述的面向微内核架构的虚拟文件构建方法，其特征在于：在所述步骤S1中：将文件系统拆分为用户态磁盘驱动服务、分区挂载服务、具体文件服务接口服务；在所述步骤S2中：编写一个轻量级虚拟文件系统模块收纳所有文件系统请求，并处理这些请求中与具体文件系统制式无关的逻辑，以静态链接库形式提供给文件系统移植人员，移植方根据接口列表中要求的文件系统接口，以填空形式填入函数指针列表完成移植。3.根据权利要求1所述的面向微内核架构的虚拟文件构建方法，其特征在于：在所述步骤S3中：提供可移植操作系统接口兼容的接口，并以动态链接的形式交与应用程序调用，具体技术方法为：在现有的musl
‑
libc源码中，扦插微内核完成文件系统逻辑的进程间通信逻辑，将之编译为一个gcc
‑
wrapper与一个动态链接库libc.so，使得应用程序在动态链接与静态链接时均能够使用自定义的函数行为，并且这些函数保持了原有的可移植操作系统接口兼容性；针对需要内核参与的文件系统相关接口，在内核提供线程调度与内存管理相关接口时完整实现，具体细节如下：通过环形队列与拉取机制建立内核与用户态的异步通信机制，将内核中的缺页事件信息传递给用户态文件系统实例，文件系统实例通过读取该信息，通过调用内核提供的页表接口，进行用户态缺页处理；在所述步骤S3中：当应用程序切实需要使用某个具体文件系统实例时，由全局的应用程序管理器加载具体的文件系统实例，当该文件系统实例已经在系统中运行时，直接建立应用程序与文件系统的通信通道。4.根据权利要求1所述的面向微内核架构的虚拟文件构建方法，其特征在于：为了保证系统的隔离性，应用程序之间的文件系统状态应该相互隔离，包括两个无关进程之间不应该能通过文件系统访问到各自的进程状态，以及无关的请求之间不应该有性能影响；在可移植操作系统接口设计中，文件描述符由系统调用产生，随后通过一系列操作文件描述符的系统调用完成对文件系统的访问，文件描述符分为三类，一是文件类型的描述符，二是目录类型的描述符，三是其他描述符；在Linux的设计中，由系统调用产生的描述符可能在不同进程之间共享偏移量数据，偏移量数据应当保存在文件系统服务端而非应用程序端。5.根据权利要求1所述的面向微内核架构的虚拟文件构建方法，其特征在于：
保存在应用程序侧的描述符信息，包括一个整型索引以及文件描述符的类型信息；保存在服务侧的entry，包含描述符偏移量信息；保存在服务侧的虚拟节点。文件描述符的索引由应用程序产生后发送给文件系统服务进行记录，文件系统服务侧会为每个描述符生成一个对应的entry，指向同一个文件的不同entry会被合并指向一个虚拟节点；文件系统服务侧，每个entry对应应用程序侧一个文件描述符，每个虚拟节点对应一个磁盘上的文件，而entry与虚拟节点之间是一个多对一的映射关系；应用程序以可移植操作系统接口兼容的接口使用文件系统，将调用转化成对应进程间通信的代码被封装到musl
‑
libc中，有关文件描述符的数据结构被分到应用部分和服务侧部分，由应用和服务协同完成对文件描述符的操作，文件系统服务侧的数据结构根据应用程序的id分别保存，保证了不同应用进程之间的数据隔离和性能隔离；文件系统装饰器部分的功能主要是接收和分发进程间通信请求；文件系统通用模块位于装饰器和具体文件系统之间，作为可选模块；装饰器和具体文件系统封装成一个静态链接库，保留与具体文件系统有关的函数指针列表，由此最小化文件系统移植过程中的重复代码；每个文件系统实现都包含：一组文件系统装饰器和文件系统通用模块，一个文件系统实现。编码过程中如果开发人员需要扩展文件系统通用模块，则编写对应模块的代码并在文件系统通用模块部分进行对接；如果开发人员需要添加新的文件系统实现，则根据文件系统装饰器内的函数指针列表进行编写，以静态链接的方式与文件系统装饰器进行组合；该框架将文件系统共同的代码逻辑抽象为文件系统装饰器；执行过程中应用程序libc模块通过将用户的可移植操作系统接口请求转化成进程间通信形式发送给文件系统管理服务；文件系统管理服务根据路径参数惰性启动文件系统实例，不同的文件系统实例被分放在不同的进程中，以此达到隔离错误的目的；随后文件系统服务处理具体请求，件系统服务包括文件系统装饰器、文件系统通用模块、一个文件系统实现；文件系统服务进程内更新该请求对应的数据结构后，将运行结果信息返回给应用程序。6.一种面向微...

【专利技术属性】
技术研发人员：胡雨奇，古金宇，臧斌宇，王肇国，
申请(专利权)人：上海交通大学，
类型：发明
国别省市：