CN112114863A - 微内核代支持的操作系统架构 - Google Patents

Abstract

本发明涉及计算机操作系统，并提出了新颖的OS架构，以提供不同代的用户应用程序和操作系统的兼容性。此外，OS还实现了基于模块的细化结构，用于自定义和对硬件功能的完全访问。可以为新功能和硬件开发OS及其内核，而不会损害和重写现有软件组件和应用程序。该架构表示为ACOM‑具有不变接口及其规范的演化的COM组件架构，允许组件自由地编程代码实现。其中包括：模块化微内核本身，OS可以同时运行各代微内核容器的可能性，包括/委托或聚合其他所需组件；特殊的编组机制通过允许可执行文件具有用于动态函数导入的单个系统接口实例的地址指针来减小标头的大小，而无需根据最新版本的OS系统库重新编译应用程序中较早的可执行文件。

Description

微内核代支持的操作系统架构

技术领域

本公开涉及计算机工程，尤其涉及提供对各代微内核同时运行的操作系统(ОS)架构。

背景技术

大多数现代操作系统是结构良好的模块化系统，能够开发、扩展和转移到新的硬件平台。OS的结构选择之一是区分单芯片架构和微内核架构。

内核是操作系统的中心部分，向应用程序提供对计算机资源(如处理器时间、内存、外部硬件以及输入和输出外围设备)的协调访问。内核通常提供文件系统和网络协议服务。微内核(μ内核)是具有最少函数集的操作系统内核。

微内核有条件地分为多代。各代的微内核在结构和解决方案方面都不同。

当前，存在许多描述OS架构的解决方案。

已知一种描述计算机操作系统的现有技术解决方案(微软公司于2006年12月14日公布的US2006282899A1)。该解决方案的缺点是无法更改内核本身的元素，只能在内核和应用程序级别添加函数。

已知一种描述包括多个各种组件的计算机操作系统的现有技术解决方案(LYNXREAL TRIME SYSTEMS INC于2000年6月13日公布的US6075939A)。在该已知的解决方案中，组件包括函数输入和输出表。该解决方案的缺点是它不提供任何架构组件的互换性。

已知许多描述各种OS架构的解决方案。例如，以下文件中公开了此类解决方案：US20100251265A1，US20090158299A1，US20080148277A1，US6308247В1。

然而，现有技术的OS架构解决方案具有降低的功能，特别是，它们都不能提供对各代微内核的同时运行。

发明内容

本发明旨在解决的技术问题是创建提供对各代微内核同时操作的操作系统架构，这在独立权利要求中进行了描述。

技术结果是创建了一种操作系统架构，该架构可同时运行各代微内核。它提供了运行为各代微内核(各种操作系统版本)开发的系统组件和应用程序的选项，并提供了通过开发OS内核而不损害现有应用程序软件函数的方式更广泛地使用平台硬件资源的选项。

由于解决了技术任务而获得的额外的技术成果是提供了微内核OS模块化；模块化原理允许根据需要启动和停止组件；例如，要纠正错误，可以更改组件代码，编译新组件，停止旧组件并启动新组件。

优选实施例提供了一种操作系统(OS)架构，该架构被配置为可同时运行各代的微内核，包括：

具有模块化结构的适应组件对象模型(ACOM)的一组互连组件；ACOM组包括从以下组中选择的每种类型的一个或多个组件：

·被配置为提供对计算机系统资源的访问和控制的管理组件；

·被配置为控制用户界面的显示组件；

·被配置为执行所应用任务的逻辑的应用程序组件；

·作为容器制成的微内核组件，其内部包含：

a.调度器组件，被配置为设置和运行任务；

b.接口总线的组件，被配置为用于完成组件的加载、注册和配置接口的任务；

其中，每个组件的标头包括接口表，该接口表包括：用于访问已加载的组件及其函数的接口的系统接口指针，以及被配置为用于在接口总线中注册组件并访问组件接口的组件工厂接口指针；

其中，模块化结构在同一OS实例中同时运行多个微内核；根据硬件选项，每个新的微内核代都通过包容或聚合机制包括先前的微内核代。

附图说明

下文将根据用于解释本发明的本质而呈现的附图描述本发明的实施例，而绝不限制本发明的范围。以下附图已附加到本申请中：

图1示出了OS架构。

图2示出了微内核架构。

图3示出了包括上一代微内核的新一代微内核。

图4示出了微内核组件的加载过程。

图5示出了组件重用机制的示例。

图6示出了循环调度的示例。

图7显示了通用可执行文件格式。

具体实施方式

在下面对本发明实施例的详细描述中，提供了多个实施例细节，以提供对本发明的清楚理解。但是，对于本领域专家来说，无论是否具有实施例细节，本发明的使用方式都是显而易见的。在其他情况下，未详细描述众所周知的方法、步骤和组件，以免模糊本发明的特定特征。

此外，从给出的说明中显而易见的是，本发明超出了所描述的实施例。维护本发明的实质和形式的多种可能的修改、改变、变化和替换对于本领域专家来说是显而易见的。

本发明旨在创建一种OS架构，该OS架构提供各代微内核的同时操作。

微内核负责实现以下功能：

1)进程调度–微内核组件之一是调度器，用于选择要转移到的已启动进程控制之一；包括同步机制；

2)委托者中断处理器–所有硬件中断和异常都转移到各自注册的进程中，以在没有微内核干扰的情况下处理一个或另一个中断，但由微内核提供服务并已注册到的事件除外(例如，调度器使用的定时器中断处理器)；

3)进程间通信–接口总线用于通过请求一个或另一个接口并注册到一个或另一个接口的事件来提供进程之间的通信。

在要求保护的解决方案中，OS架构是基于ACOM的。OS架构包括多个相互连接的ACOM组件，这些组件具有模块化结构并支持各代的微内核操作。组件是分布式应用程序的组成部分。模块化原理允许根据需要运行和停止组件，例如，纠正错误，可以更改组件代码，编译新组件，停止旧组件并启动新组件。

所有基本的OS元素，包括其微内核，都由具有交互接口的组件组成。微内核本身也是带有接口的组件。在要求保护的ACOM技术中，存在组件重用机制：聚合和包容，用于在新的微内核代中重用旧的微内核版本。

ACOM基于微软COM技术的演进概念。

在要求保护的解决方案中，提供微内核代支持的操作系统架构基于以下用途：

1)具有QueryInterface、AddRef和Release方法的IUnknown接口。在ACOM中，该接口称为IEcoUnknown，已知COM技术中的GUID组件标识符为128位，而在所要求保护的解决方案中，它可以为64位、128位或256位。

2)类工厂，然而在ACOM，IСlassFactory接口称为IEcoComponentFactory，并将其用作组件实例创建机制。

3)组件重用机制–包容和聚合。包容和聚合是编程技术，其中一个(外部)组件使用另一个(内部)组件，即，外部组件聚合或包容内部组件。两种技术之间的差异在于，在包容的情况下，外部组件会实现内部组件接口，因此，它可以在调用之前控制内部组件。在聚合的情况下，外部组件不实现内部组件接口，而是将控制直接传输给内部组件。下图(图5)显示了技术上的差异。

这些技术与接口使用概念(虚拟函数表)相结合，提供了支持各代微内核运行的选项。

4)编组机制。

与已知的现有技术OS架构相反，提出的架构具有以下特点：

首先，它支持多代微内核组件，可同时运行各代的微内核。每个新的微内核代(N+1，其中N是当前代)都需要支持新的硬件处理器架构，这是计算机工程进化和技术发展的一部分。它可以包括CPU或控制器中架构和计算逻辑的变化，以及所提供的位数或程序以及I/O接口的变化。为了在OS级别支持此类变化，开发了新的微内核代。启动针对特定处理器架构(因此针对特定微内核代)开发的应用程序时，OS将校验加载的组件；如果不可用，它将所需的微内核加载到计算机内存中。在这种情况下，已加载的N-代微内核会将指向自己的指针注册到运行在OS中的N+1微内核(如果已启动)或者以后的N+M微内核中。在同一操作系统实例中同时运行多个微内核代的事实允许同时使用为各种平台架构(因此是各种OS微内核)开发的任何应用程序。在发布新的OS版本(代)后，它不会失去对较旧应用程序的兼容性和可操作性，从而节省了软件开发人员以及终端用户的投资，从而分别解决了由于新替代OS版本以及购买新软件版本中的程序接口和内核更改而导致的应用程序软件不兼容问题。

第二个显著特征是，微内核组件本身具有容器的形式，由诸如调度器组件和接口总线组件之类的组件组成，这些组件可根据所需的OS任务和操作模式使用内部组件的各种实现。例如，可以选择切换到实时模式或调度机制或资源访问分配的其他特定实现。

根据图1，使用ACOM技术根据客户端-服务器模式来构造所要求保护的OS架构(100)。包括微内核(图2)在内的所有OS架构元素都是组件。每个组件都有带有接口描述的规范，而接口描述又允许按照规范独立地实现一个或另一个架构元素。根据模块化原则，该架构是基于组件的，从而允许根据设置的任务在OS中仅包括必要的组件(模块)。由于组件重用机制：在ACOM聚合和包容下，新一代微内核可能包含上一代微内核(图3)。组件重用机制适用于根据ACOM技术构造的整个基于组件的OS架构。

ACOM组包含从以下组中选择的每种类型的一个或多个组件：

·被配置为提供对计算机系统资源的访问和控制的管理组件；

·被配置为控制用户界面的显示组件；

·被配置为执行所应用任务的逻辑的应用程序组件；

·作为容器制成的微内核组件，其内部包含：

a.调度器组件，被配置为设置和运行任务；

b.接口总线组件，被配置为用于完成组件的加载、注册和配置接口的任务；

其中，每个组件的标头包括接口表，该接口表包括：用于访问已加载的组件及其函数的接口的系统接口指针，以及被配置为用于在接口总线中注册组件并访问组件接口的组件工厂接口指针。模块化结构可在同一OS实例中同时运行多个微内核。根据硬件选项，每个新的微内核代都通过包容或聚合机制包括先前的微内核代。

图4显示了微内核组件的加载过程。

系统加载器是直接依赖于硬件的系统部件。

在最低配置下，加载器加载系统微内核和“启动应用程序”。

作为一种选择，加载器可以加载以下组件：

-内存管理器；

-设备管理器；

-文件管理器；；

-自定义组件。

将微内核加载到内存后，加载器会根据链接情况将已加载的组件(例如内存管理器、设备管理器、文件管理器和自定义组件)注册到接口总线中。然后，加载器加载“启动应用程序”，其任务上下文存储在调度器中，并将控制传递给它。至此，OS启动过程完成。然后，启动应用程序可以创建和管理任务。

根据任务类型，“启动应用程序”可以用作独立的执行单元或用作生成进程的壳。

最低OS配置的加载阶段如下：

-接通电源后，基本引导过程将启动以搜索并读取引导扇区，然后该过程将控制传递到引导扇区程序。

-根据文件系统的类型，位于引导扇区中的程序会将位于文件系统上的主OS加载器加载到可用存储区，并将控制传递给加载器。

-OS加载器是一种程序，用于根据启动应用程序的初始运行的组件来实现OS加载场景(scenario)。OS加载场景的一种实现是使用交互式菜单，该菜单用于选择文件系统中的组件。

-第一步，OS加载器加载微内核组件。加载器可以根据场景将组件加载到任何可用内存区域，并通过规范中描述的微内核组件接口(例如堆栈大小，内存区域等)将其初始化(准备运行)。

-第二步，OS加载器加载调度器组件。加载器可以根据场景将调度器组件加载到任何可用内存区域。

-第三步，OS加载器加载接口总线组件。加载器可以根据场景将接口总线组件加载到任何可用的内存区域。

-成功加载微内核组件(例如调度器和接口总线)后，加载器通过调用微内核接口初始化方法，将指针作为参数指向发送给调度器和接口总线组件，来初始化微内核中的调度器和接口总线组件。

但是，应该强调的是，由于微内核组件以及调度器和接口总线组件具有按照规范中描述的接口，因此任何开发人员都可以按照规范进行自己的实现，无论是微内核、调度器或接口总线组件。例如：一个独立的开发人员已经开发了一个调度器，其中的进程切换时间减少了处理器时间的几个周期，但是，该组件具有规范中描述的接口。因此，可以在OS加载场景中设置由独立开发人员加载调度器组件。

-操作系统加载方案的下一步是在开始启动应用程序必不可少的可选组件的接口总线中进行加载和注册。此步骤不是必需的，并且取决于启动应用程序使用的组件。以需求最大的组件之一–内存管理组件为例。根据情况，加载器可以将内存管理组件加载到任何可用的内存区域。

-成功加载可选组件后，OS加载器调用接口总线组件接口的注册方法以在系统中进行组件注册。

但是，应该强调的是，在大多数操作系统中，内存管理是操作系统不可分割的部分。所要求保护的OS架构的显著特征是由于各种内存分配方法，内存管理是一项可选任务：-不涉及外部存储器(固定分区、动态分区、可重定位分区)，并且涉及外部存储器(分页、分段或分页分段)。从这个角度来看，内存管理组件规范描述了接口要求，但没有规范内存分配方法。因此，内存管理组件开发人员可以使用内存管理方法，这在他们看来是最有效的。在要求保护的OS架构中，不可变的接口(输入和输出参数)和严格按照规范的实施非常重要。

位于内存或文件系统中的组件的接口通过接口总线组件进行调用。

将微内核加载到内存后，加载器会根据链接场景在接口总线上注册已加载的系统组件，例如内存管理组件、设备管理器、文件管理器等。

但是，应该强调的是，接口总线组件注册表仅包含位于内存中组件上的数据。组件注册的注册表容量有限。为了扩展接口总线注册表，有必要加载内存管理器，这是由加载器在微内核加载和注册到接口总线注册表时执行的。位于文件系统中的组件通过文件管理器加载。在使用位于文件系统中的组件的情况下，加载器必须将文件管理器加载到系统内存中，并将其注册到接口总线注册表中。

关于调度器组件，它还具有按照规范描述的接口，该接口提供了根据任务制作一组具有各种特性的调度器(具有各种调度算法)。

例如，可以使用时隙算法以最简单的任务实现调度来实现调度器。将处理器时隙分配给每个任务。当时隙结束时，调度器将任务放在队列的末尾(如图6所示)。

OS可执行文件格式如下所述。

通常的可执行文件格式如图7所示。标头包含有关文件及其基本特征的常规信息。接口表包含IEcoUnknown接口地址指针。主指针(链接)是指向系统接口(EcoSystem1)的指针；此接口提供对导入的组件及其方法(函数)接口的访问。接口表中的第二个重要指针是指向组件工厂接口(IEcoComponentFactory)的指针；通过该接口，系统在接口总线中注册组件并创建数据实例。接口表后跟特定的操作系统标头、代码和数据块(段)。

格式的一个显著特征是没有函数导入和导出表，这大大减少了可执行文件标头的容量。由于不断的开发，改进和新功能的添加，微内核OS壳在加载过程时会在开发的一个或另一个阶段创建最新版本的系统接口实例。

由于接口表包含IEcoUnknown接口地址指针，因此OS壳(尤其是系统接口)将写入指针地址，例如第4版系统接口的IEcoSystem4。

使用IEcoUnknown接口的QueryInterface方法的可执行进程(无论是旧版本还是最新版本，该进程是使用IEcoSystem1系统接口为内核的第一个版本开发的或使用IEcoSystem4系统接口为内核的最新版本开发的)调用它可以使用的系统接口的版本。对于第一种情况，IEcoSystem4系统接口将创建IEcoSystem1系统接口实例并返回相应的指针，对于第二种情况，IEcoUnknown将返回指向自身的指针，因为IEcoUnknown接口地址与IEcoSystem4地址一致。

因此，在二进制级别的最新OS版本中支持早期开发的程序的可操作性，即不需要重新编译。

作为比较，一个简单的使用libc库的printf函数为2.x内核RedHat OS版本编写的“Hello World！”程序没有重新编译无法在3.x内核RedHat Os版本上运行，并且将显示“找不到libc2.x库”错误。

上述交互模式提供的另一个突出功能是，为最新OS版本开发的应用程序(进程)可以解决其最低功能，并且可以在早期OS版本上运行(执行)。换句话说，如果某个进程(使用IEcoUnknown接口的QueryInterface方法)调用了IEcoSystem4系统接口，并且返回了空指针，则该进程可以调用指向早期系统接口版本的指针，例如IEcoSystem3，分别限制了其能力。现有技术的操作系统都没有在可执行文件级别上使用这种方法。

因此，在可执行文件级别上实现了一个优势：

1)导入函数只有一个系统接口指针地址；

2)无需根据OS系统库的最新版本重新编译较早的软件版本；

3)可以在较早OS版本上以缩减功能模式执行为新OS版本开发的软件。

本申请材料包含技术方案的优选实施方式，其不应被用作限制其他私有的实施方式，其不超出所要求的法律保护范围并且对于本领域专家而言是显而易见的。

Claims (1)

1.一种操作系统(OS)架构，被配置为同时运行各代的微内核，包括：

具有模块化结构的适应组件对象模型(ACOM)的一组互连组件；ACOM组包括从以下组中选择的每种类型的一个或多个组件：

·被配置为提供对计算机系统资源的访问和控制的管理组件；

·被配置为控制用户界面的显示组件；

·被配置为执行所应用任务的逻辑的应用程序组件；

·作为容器制成的微内核组件，其内部包含：

a.调度器组件，被配置为设置和运行任务；

b.接口总线组件，被配置为用于完成组件的加载、注册和配置接口的任务；

其中，每个组件的标头包括接口表，该接口表包括：用于访问已加载的组件及其函数的接口的系统接口指针，以及被配置为用于在接口总线中注册组件并访问组件接口的组件工厂接口指针；

其中，模块化结构在同一OS实例中同时运行多个微内核；根据硬件选项，每个新的微内核代都通过包容或聚合机制包括先前的微内核代。

Images