对于某些计算机程序，在限定的时段内或在限定的时刻执行程序中 的步骤是至关重要的。这种程序的示例有用于对移动电话进行操作的控 制程序，或用于对专用交换分机(PBX)或蜂窝基站进行操作的控制程 序。通常，该程序必须在外部事件或状态变化之后的特定时间或特定时 间之内按始终如一的方式对该事件进行响应。这被称为“实时”操作。
然而，对于许多其他程序，执行该程序的时间并不是很重要。这适 用于大部分普通计算机程序，包括电子表格程序、字处理程序、薪酬软 件包、以及通用的报告或分析程序。另一方面，尽管由这种程序花费的 确切时间并不是至关重要，但是在大部分情况下，只要有可能，用户就 更喜欢更快的执行。
应用程序通过操作系统与它们在其上运行的计算机交互。通过利用 操作系统的应用编程接口(API)，可按照可移植方式来编写应用程序， 使其可以在具有不同硬件资源的不同计算机上执行。此外，诸如Linux 或Windows的通用操作系统提供多任务处理；换言之，这些操作系统允 许几个程序并行运行。为此，这些操作系统提供调度；换言之，它们根 据调度算法为各个程序分配时间，从而在不同的程序之间共享对计算机 资源的使用。这种操作系统被广泛采用，但是它们通常不能用于运行实 时应用，因此它们对于很多控制或通信任务都不适合。
因此，针对这种任务，已经开发了实时操作系统；一个示例是 ChorusOS(也称作Chorus)及其衍生物。作为开放源码软件，Chorus可 以从http：//www.experimentalstuff.com/Technologies/ChorusOS/index.html 以及http：//www.jaluna.com/处的Jaluna获得。
在“ChorusOS Features and Architecture overview”，Francois Armand， Sun Technical Report(2001年8月，第222页)(可以从 http：//www.jaluna.com/developer/papers/COSDESPERF.pdf获得)中，对其 进行了描述。
这些操作系统也可以用于运行其他类型的程序。然而，可以理解， 用户希望能够运行为诸如Windows或Linux的通用操作系统编写的大量 “传统”程序，而不必为在实时操作系统中运行而重写这些程序。
可以提供“双引导”系统，使得用户可以运行一个操作系统或另一 个操作系统，但是存在很多希望在运行实时程序的同时能够运行“传统” 程序的情况。例如，电信网络基础设施设备、第三代移动电话和其他高 级电话、以及高级电子游戏设备，可能既需要实时应用(例如，游戏播 放图形)又需要非实时应用(游戏下载)。
在US 5903752和US 5721922中，尝试通过在非实时操作系统(例 如Windows)的中断处理环境中提供实时多任务内核而将实时环境并入 非实时操作系统中。
一种已广泛应用的方案是“仿真”。通常，编写仿真程序以在实时操 作系统下运行，该仿真程序对为通用操作系统编写的程序的各个指令进 行解析，并在实时操作系统下执行对应的一系列指令。然而，由于总是 由很多指令来代替一条指令，所以仿真使计算机负担更重，并导致性能 更慢。基于提供虚拟机(例如，JavaTM虚拟机)的方法存在类似的问题。 虚拟机实现的示例有EP 1059582、US 5499379、以及US 4764864。
US 5995745(Yodaiken)中描述了另一种类似的技术。Yodaiken描 述了这样一种系统：其中，多任务实时操作系统将通用操作系统作为其 任务之一来运行，必要时优先执行实时任务。
另一方法是如在例如EP 0360135和1990年9月的ELECTRONICS 中第62页的论文“Merging real-time processing and UNIX V”(Gosch)中 所描述的，将实时操作系统作为通用操作系统的一个模块来运行。在这 种情况下，为了使得与通用操作系统有关的硬件中断不应优先于实时操 作系统而选择性地屏蔽硬件中断。
另一方法是在http：//opersys.com/ftp/pub/Adeos/adeos.pdf的白皮书中 描述的ADEOS(操作系统的自适应域环境)方法。
ADEOS提供了超微内核，超微内核除了其他功能之外还用于运行多 个操作系统，尽管它看起来仅是利用Linux而实现的。对ADEOS的一个 建议使用是允许ADEOS向RTAI(Linux的实时应用接口)发布中断， 对此参见：
http：//www.aero.polimi.it/～rtai/applications/。
EP 1054332描述了其中由“切换单元”(并未为了充分理解而对其进 行充分详细的描述)来运行实时操作系统和通用操作系统的系统。由公 共中断处理器来处理硬件中断，而在一些实施例中，由实时操作系统来 处理硬件中断，该实时操作系统然后生成较低优先级的软件中断，这些 软件中断由次要操作系统中的例程来处理。

本发明的一个目的是提供一种即使多个操作系统是出于不同的目的 而设计出来的也能够同时运行这些操作系统的改进系统、方法以及计算 机程序。具体来说，本发明旨在使得所述多个操作系统中的一个操作系 统(例如，实时操作系统)可以不受打扰地运行、而另一个操作系统(例 如，通用操作系统)可以利用计算机的剩余资源尽可能好地运行。更具 体地说，本发明旨在提供可以使用精简指令集计算机(RISC)(例如使用 ARM处理器的精简指令集计算机)的系统。
因此，在权利要求中限定了本发明的多个方面。本说明书通过引用 并入我们先前提交的以下申请：2003年4月9日提交的欧洲申请 EP03290894.9、2004年4月7日在EPO提交的PCT/EP04/003731以及2003 年10月1日提交的EP03292428.4。
对于基于ARM处理器的许多架构，一个特别的问题是高速缓存单 元使用虚拟寻址模式。当运行多个操作系统时，每个操作系统都在其自 己的存储器空间中，每个操作系统都使用虚拟存储器到物理存储器地址 的不同映射。这会导致在切换到另一操作系统之后从高速缓存中获取到 错误的数据。解决该问题的一个途径是在每次进行操作系统切换时都对 高速缓存的内容进行刷新。然而，我们已经认识到，这对于实时应用来 说是不受欢迎的，因为首先这增大了切换的延迟、其次在刷新高速缓存 之后在初始时会使存储器存取变慢。因此，在本发明的一个方面中，我 们强制这些操作系统全部使用同一内核虚拟映射。
另一问题是ARM处理器具有许多辅助执行模式(5或6个，这与在 大部分处理器上看到的平常的“用户”和“管理员”模式不同)。因此， 在操作系统之间进行改变可能会涉及附加地在执行模式之间发生改变。 为了使得可以发生这种改变，每次在操作系统之间进行切换时都需要保 存所有寄存器的状态(例如，保存到堆栈中)。这将使这种切换变慢。因 此，在本发明的一个方面中，我们要求所有的操作系统都按“擦除 (scratch)”模式使用有关的寄存器(例如寄存器13到15)，从而这些操 作系统不关心如何找到或留下它们。我们的观察结果是，许多操作系统 都是这样做的；在其他情况下，可能有必要对操作系统的一些部分进行 改写。然后操作系统切换回到“管理员”模式，从而到超微内核(由此 到其他操作系统)的所有转移都只从管理员模式进行。这样，当操作系 统切换(例如，在它完成了操作时通过调用空闲任务来切换)到另一操 作系统时，它不必保存这些寄存器状态。
在本发明的一个方面中，我们规定，当处于较高模式时，操作系统 不能被先占——我们已经发现，操作系统通常只针对非常短的代码段使 用这种模式。
根据以下说明、权利要求书以及附图，其他方面、实施例以及优选 特征及对应的优点将变得明了。

现在将参照附图仅以示例的方式对本发明的实施例进行描述，在附 图中：
图1是示出可以执行本发明的计算机系统的部件的框图；
图2a是例示了现有技术中的软件结构的图；
图2b是例示了根据本实施例的软件结构的对应图；
图3是示出为图1的计算机创建图2b的软件的多个阶段的流程图；
图4示出了形成图2b的一部分的硬件资源分配程序的组成部分；
图5例示了在引导和初始化序列中使用的程序；
图6例示了在引导或初始化处理中使用的系统存储器映像；
图7例示了从主要操作系统到次要操作系统的转移；
图8例示了从次要操作系统到主要操作系统的转移；
图9a例示了根据本发明的在不同操作系统上运行的应用程序之间的 通信；
图9b例示了根据本发明的在不同计算机上的不同操作系统上运行 的应用程序之间的通信；
图10例示了操作系统使用的存储器映射；以及
图11例示了超微内核与操作系统之间的接口。

总体介绍
系统硬件
可以应用本系统的计算机系统100包括：中央处理单元(CPU)102， 例如可以从ARM有限公司( www.arm.com)获得并且如 http：//www.arm.com/documentation/ARMProcessor_Cores/index.html处的 技术手册和数据表中所描述的ARM处理器，该CPU 102经由系统总线 104(包括控制、数据和地址总线)连接到只读存储器(ROM)芯片106； 一组或更多组(bank)随机存取存储器(RAM)芯片108；盘控制器装 置110(例如，IDE或SCSI控制器，其与软盘驱动器、硬盘驱动器以及 诸如DVD驱动器的附加可移除介质驱动器相连接)；一个或更多个输入/ 输出端口112(例如，一个或更多个USB端口控制器，和/或用于与打印 机等相连接的并行端口控制器)；用于与外部或内部外设进行总线连接的 扩展总线114(例如，PCI总线)；以及其他系统芯片116(例如，图形或 声音设备)。这种类型的计算机的示例为个人计算机(PC)和工作站。然 而，这里还公开了将本发明应用于其他计算设备，例如大型机、控制系 统中的嵌入式微计算机和PDA(在这种情况下可以省略的所示装置中的 一部分，例如盘驱动器控制器)。
软件的管理
参照图2a，在使用时，图1的计算机100运行常驻程序，这些常驻 程序包括：操作系统内核202(其提供使得CPU可以访问图1所示的其 他装置的输出例程)；操作系统用户接口或表示层204(例如X Windows)； 中间件层206(提供联网软件和协议，例如TCP/IP栈)；以及应用程序 208a、208b，其通过调用构成操作系统内核202的API例程来运行。
该操作系统内核具有多个任务，具体来说：
·调度(即，在运行的不同应用程序之间共享CPU和相关资源)；
·存储器管理(即，向各个任务分配存储器，并且在需要的情况下， 将数据和程序从存储器换出来、添加到盘驱动器)；
·提供文件系统；
·提供对设备的访问(通常通过驱动程序)；
·中断处理；
·提供应用编程接口，使得应用程序能够与系统资源和用户进行交 互。
对于Unix，内核可以是所谓的“单内核”，在这种情况下设备驱动 程序构成该内核本身的一部分。另选的是，对于Chorus，内核可以是“微 内核”，在这种情况下设备驱动程序与内核是分开的。
然后，在使用时，当启动计算机100时，存储在ROM 106中的自举 程序访问盘控制器110，以从盘上的永久性存储器将操作系统的文件处理 部分读取到RAM 108中，然后将操作系统的其余部分加载到RAM 108 的区域中。操作系统然后通过盘控制器110从盘驱动器读取任何应用程 序，在RAM 108中为每个应用程序分配空间，并将各个应用程序存储在 其所分配的存储器空间中。
在应用程序的操作期间，操作系统的调度程序部分根据调度策略在 不同应用程序之间划分CPU的使用，使得各个应用程序可以分享处理器 的时间。该调度程序部分还通过“换出”不常用的应用程序或数据(即， 将它们从RAM 108去除以释放空间，并将它们存储到盘上)来管理存储 器资源的使用。
最后，从应用程序调用构成应用编程接口(API)的例程，以执行诸 如输入和输出的功能，并且操作系统的中断处理例程对中断和事件进行 响应。
优选实施例的原理的概述
在优选实施例中，对要在计算机100上使用的各个操作系统201、202 略微进行改写，并创建新的低层程序400(在此被称为“硬件资源分配程 序”，并且有时被称为“超微内核”，尽管其并不是操作系统的内核)。硬 件资源分配程序400是特定类型的CPU 102专用的，这是因为它与处理 器进行交互。由于将变得显而易见的原因，经修改的操作系统的版本201、 202也是硬件专用的操作系统。
硬件资源分配程序400本身不是操作系统。其根本不与应用程序进 行交互，并具有非常有限的功能。它也不是虚拟机或者仿真器；为了进 行协作，它需要修改操作系统，尽管它将大部分的处理留给了操作系统 本身，这些操作系统在处理器上运行它们的本机码。
硬件资源分配程序400执行下面的基本功能：
·加载并启动多个操作系统中的每一个；
·为这些操作系统中的每一个分配存储器和其他系统资源；
·对不同操作系统的操作进行调度(即，在它们之间划分CPU时间， 并管理它们之间的切换)；
·提供对需要由操作系统共享的那些系统设备进行间接访问的“虚 拟化设备”方法(使设备“虚拟化”)；
·在这些操作系统之间提供通信链路，以使得在不同操作系统上运 行的应用程序能够彼此进行通信。
本实施例并不平等地对待这些操作系统。而是将这些操作系统中的 一个选择作为“关键”操作系统(这将是实时操作系统)，而将各个其他 操作系统视为“非关键”或“次要”操作系统(这将是各个通用操作系 统，例如Linux)。
当设计硬件资源分配程序时，其设置有对可用系统资源(即，设备 和存储器)进行列表的数据结构(例如表)，以使得能够将尽可能多的系 统设备静态唯一地分配给这些操作系统中的一个或另一个。
例如，可以将并行打印机端口静态地分配给经常运行需要产生打印 机输出的应用程序的通用操作系统202。另一方面，可以将ISDN数字线 适配器端口永久地分配给实时操作系统201以进行通信。只要有可能就 对设备进行这种静态分配意味着各个操作系统可以使用其现有的驱动程 序来访问静态分配的设备而无需调用硬件资源分配程序。因此，在访问 这些设备的执行速度方面没有损失(如果这些设备用作虚拟机或仿真器 则将存在该损失)。
在必须共享系统设备的情况下，硬件资源分配程序对由非关键操作 系统对这些设备的使用进行虚拟化，并使用提供给关键操作系统的驱动 程序来进行访问。同样，为了进行中断处理，将中断传递给关键操作系 统中断处理例程，该例程对中断进行处理(如果该中断是针对关键操作 系统的话)、或者通过硬件资源分配程序将其传递回去以转发给非关键操 作系统(如果该中断是针对非关键操作系统的话)。
在引导时，首先加载硬件资源分配程序，然后其按照如下的预定顺 序加载各个操作系统：从关键操作系统开始，然后依次是各个次要操作 系统。根据所述表向关键操作系统分配其所需的资源，并且该关键操作 系统具有固定的存储器空间以在其中进行操作。然后从可用的剩余资源 中依次向各个次要操作系统分配其所需的资源和存储器空间。
因此，根据本实施例，通过为各个操作系统分配其自己的存储器空 间，并且通过向这些操作系统排他地提供静态设备分配，使得由这些操 作系统使用的资源在物理上尽可能地分离；仅共享必需共享的设备。
在操作中，硬件资源分配调度程序允许关键操作系统进行操作直到 其结束其任务为止，然后依次将控制传递回各个非关键操作系统，直到 出现下一中断或事件为止。
因此，本实施例允许多操作系统环境，其中关键操作系统的操作实 际上不变(因为它使用其原始驱动程序，并第一个访问任何中断和事件 处理)。次要操作系统能够在剩余的处理器时间内有效地进行操作，这是 因为在大多数情况下它们将使用它们自己原有的驱动程序并独占地访问 多个系统设备。最后，由于硬件资源分配程序仅处理有限的功能，所以 硬件资源分配程序本身可以是很小的程序，从而可以节省系统资源。
因为该优选实施例仅涉及对标准商业操作系统(它们已经适用于特 定的计算机100)的有限改变，所以该优选实施例在创建和维护方面也是 经济的。此外，由于对操作系统的改变限于处理例如中断处理的事务的 架构特定文件、以及与特定类型的计算机100交互并且不可能像操作系 统的其余部分那样频繁地改变的初始化时的构造，所以在使相同操作系 统的新版本适应以多操作系统的方式进行工作方面要做的事情可能很少 或没有。
对优选实施例的详细描述
在本实施例中，计算机100是Intel 386系列处理器(例如Pentium 处理器)和Motorola PowerPC 750(精简指令集计算机或“RISC”)计算 机(步骤302)。关键操作系统201是C5操作系统(Jaluna-1实时微内核， ChorusOS系统的第五代开放源码版本，可以从http：//www.jaluna.com免 费下载而得到)。
在步骤306，将ChorusOS操作系统内核201进行修改，以在多操作 系统模式下进行操作，以支持新平台的相同方式来进行处理(即，编写 新的板卡支持包以使得能够在具有相同CPU但不同系统设备的新计算机 上执行)。将引导和初始化序列修改为使得实时操作系统可以由硬件资源 分配程序在其所分配的存储器空间中启动，而不是自己启动。对初始化 序列的硬件搜索阶段进行修改，以防止关键操作系统访问分配给其他辅 助系统的硬件资源。其从硬件资源分配程序读取静态硬件分配表以检测 其可用的设备。
向关键操作系统添加陷阱(trap)调用2012，以检测状态并请求某 些动作作为响应。陷阱调用在此是指使得处理器保存当前上下文 (context)(例如，寄存器的状态)并加载新上下文的调用。因此，在使 用虚拟存储器编址的情况下，改变地址指针。
例如，当实时操作系统201到达终止点(并停止要求处理器资源) 时，可以将控制传递回硬件资源分配程序，并发送“空闲”陷阱调用， 以启动次要操作系统。许多处理器都具有“停止”指令。在某些情况下， 仅管理员层代码(例如操作系统而不是应用程序)才可以包括这种“停 止”指令。在本实施例中，对所有操作系统都进行重写，以去除“停止” 指令并将它们替换为在被调用时发出“空闲”陷阱调用的“空闲”例程 (例如，执行线程)。
板卡支持包的一些驱动程序特别有助于硬件资源分配程序对用于次 要操作系统的共享设备进行虚拟化。
添加附加的“虚拟”驱动程序2014，该“虚拟”驱动程序2014对 于操作系统表现为提供对输入/输出(I/O)总线的访问，使得能够向总线 写数据。实际上，虚拟总线驱动程序2014使用存储器作为通信介质；其 导出一些专用存储器(用于输入数据)并导入(import)由其他系统导出 的存储器(用于输出数据)。这样，操作系统201(或在操作系统上运行 的应用程序)可以向另一操作系统(或在其上运行的应用程序)传递数 据，好像它们是在由真实I/O总线连接的独立机器上运行的两个操作系统 一样。
将次要操作系统202选择(步骤308)为具有内核版本2.4.18的Linux (步骤308)。
在步骤310，将次要操作系统内核202修改为使得其能够在多操作 系统环境下运行，该多操作系统环境被视为新的硬件架构。如在步骤306 一样，对引导和初始化序列进行修改，以使得次要操作系统可以由硬件 资源分配程序来启动，并防止其访问分配给其他系统的硬件资源(如在 硬件资源分配程序表中所指定的)。如在步骤306一样，添加陷阱调用 2022，以将控制传递给硬件资源分配程序。
将用于共享系统设备的本地驱动程序替换为用于处理被硬件资源分 配程序进行了虚拟化的设备(中断控制器、I/O总线桥、系统定时器和实 时时钟)的新驱动程序2028。这些驱动程序执行对硬件资源分配程序的 虚拟设备处理程序416的调用，以对计算机100的各个设备执行某些操 作。硬件资源分配程序的各个这种虚拟设备处理程序416与关键操作系 统中的“对等”驱动例程配对，该驱动例程用于与系统设备直接进行交 互。因此，将对虚拟设备处理程序的调用中继到关键系统中的用于该虚 拟化设备的对等驱动程序，以进行实际的设备访问。如在步骤306，设置 对于虚拟I/O总线的读写驱动程序2024，以使得能够进行操作系统间通 信。
对次要操作系统的中断服务例程进行修改，以提供多个虚拟中断服 务例程2026，各个虚拟中断服务例程2026对相应的虚拟中断(所述虚拟 中断为由硬件资源分配程序的中断处理例程412发出的调用的形式)进 行响应，而不对实际中断或事件进行响应。还对次要操作系统的例程(包 括中断服务例程)进行修改，以去除对硬件中断的屏蔽(至少在除了关 键操作的所有操作中去除)。这样，关键操作系统201因此优先于次要操 作系统202......；换言之，对虚拟中断的次要操作系统响应本身可以被关 键操作系统201的实际中断而中断。这通常包括：
·屏蔽/去屏蔽事件(处理器级的中断)；
·保存/恢复事件屏蔽状态；
·识别中断源(中断控制器设备)；
·在源级屏蔽/去屏蔽中断(中断控制器设备)。
添加新的虚拟设备驱动程序2028，用于访问所共享的硬件设备(I/O 总线桥、系统控制台、系统定时器和实时时钟)。这些驱动程序执行对硬 件资源分配程序的虚拟设备处理程序416的调用，以向计算机100的各 个设备写入数据或从其读取数据。
为实现该操作，在本实施例中通过添加具有少量经修改文件的新的 虚拟硬件资源分配程序架构子树(用于I-386和PowerPC变体的nk-i386 和nk-ppc)来修改Linux内核207。以原有的形式重新使用未改变的文件。 保留原始子树但并不使用。
在步骤312，编写硬件资源分配程序400。硬件资源分配程序包括提 供用于以下功能(如图4所示)的例程的代码：
·引导并初始化自身(402)；
·存储用于存储硬件资源(诸如端口的设备)的列表以及表示各个 资源被唯一分配给哪个操作系统的分配目录的表(403)；
·引导并初始化完成了硬件资源分配程序分配表的关键操作系统 (404)；
·引导并初始化次要操作系统(406)；
·在操作系统之间进行切换(408)；
·在操作系统之间进行调度(410)；
·处理中断(使用实时操作系统中断服务例程，并在必要的情况下 向次要操作系统的虚拟中断服务例程供应数据)(412)；
·处理来自各个操作系统的陷阱调用(414)；
·处理来自次要操作系统的对共享设备的访问(416)；
·处理在虚拟I/O总线上的操作系统间通信(418)。
在进一步的实施例(下面描述)中，还可以提供系统调试框架。
操作系统切换程序408
为了从一个操作系统切换到另一操作系统，将操作系统切换程序408 设置为保存当前执行的操作系统的“上下文”——状态变量组的当前值， 例如寄存器值；恢复所存储的另一操作系统的上下文；以及调用该另一 操作系统以在其退出的地方重新开始执行。在处理器使用多段存储器以 及虚拟或间接寻址技术的情况下，由此交换存储有指向当前存储器空间 的指针的寄存器或数据结构。例如，操作系统分别在由包括指向不同的 这些存储器空间的指针值的上下文限定的这些空间中进行操作。
具体地说，切换程序提供：
·在当前操作系统空闲时，从当前运行的操作系统显式切换(例如， 陷阱调用)到下一个所调度的操作系统；以及
·当产生硬件中断时，从次要操作系统隐式切换到关键操作系统。
如下所述，这些切换可以在陷阱调用或者实际或虚拟中断时产生。
调度程序410
调度程序410通过在退出一个操作系统之后选择下一个要切换到的 次要操作系统(如果存在一个以上的次要操作系统)，向各个操作系统分 配可用处理时间中的一部分。在本实施例中，基于固定的优先级调度来 选择各个操作系统。这里也可以考虑其他实施例，这些实施例允许基于 分时或保证处理器时间的最小百分比的规范。然而，在各种情况下，关 键操作系统仅在处于空闲状态时被抢占。
在进一步的实施例中，关键操作系统可以在其可以被抢占时明确地 通知调度程序410，从而使得所有次要操作系统可以对CPU进行一些访 问，以执行优先级比仍在关键系统中运行的任务高的任务。因此，在一 个示例中，关键操作系统的中断服务例程不能被抢占，从而关键操作系 统始终可以对来自实时时钟的外部事件或定时信号进行响应，以保持实 时操作。
处理虚拟化处理器异常
硬件资源分配程序被设置为提供如下的对处理器异常(例如，CPU 中断或协处理器中断)进行处理的机制：
·首先，通过关键操作系统拦截处理器异常；
·其次，向一个或更多个次要操作系统发布对应的虚拟异常；存储 该数据，并在调度程序下一次调用该次要操作系统时，调用该次要 操作系统中的对应虚拟中断服务例程2026；
·第三，对来自次要操作系统内的任何待处理虚拟异常进行屏蔽或 去屏蔽。
虚拟化的异常通常用于两个不同的目的：
·首先，向次要操作系统转发硬件设备中断(作为异步处理器异常 来传递这些硬件设备中断)；
·其次，实现操作系统间交叉中断，即由一个系统对另一中断而产 生的中断(作为同步异常来传递这些中断)。
陷阱调用处理程序414
陷阱调用处理程序的操作将根据以下描述而变得明了。其主要目的 是在第一个操作系统停止(因此不需要CPU资源)时允许调度程序和切 换程序改变到另一操作系统。另一作用是调用诸如系统控制台的硬件资 源分配程序服务，以在与后面的实施例相关描述的调试中使用。
虚拟化设备416
如上所述，对于各个共享设备(例如，中断控制器、总线桥、系统 定时器、实时时钟)，各个操作系统都提供构成用于该装置的对等级驱动 程序组的设备驱动程序。该实时操作系统提供用于实际访问该设备的驱 动程序，而其他操作系统提供虚拟设备驱动程序。
硬件资源分配程序的共享设备处理程序416为各个设备提供存储数 据结构，以由该设备的所有对等设备驱动程序进行访问。当要访问或已 经访问该设备时，设备驱动程序使用该访问的细节来更新存储在对应数 据结构中的数据。对等驱动程序使用交叉中断(如上所述)来通过信号 发送事件，以通知其他对等设备刚更新了数据结构。
用于访问中断控制器设备的驱动程序使用上述的虚拟化异常机制来 如下处理硬件中断：
·关键操作系统设备驱动程序对硬件中断进行处理，并将它们作为 虚拟化异常转发给次要对等驱动程序；
·次要操作系统通过使用上述的虚拟化异常屏蔽和去屏蔽例程而使 能和禁用中断。
只有在与I/O总线及其桥相连接的设备并非全部分配给同一操作系 统的情况下才必须共享I/O总线及其桥。因此，在分配设备时，尽可能地 将与同一I/O总线相连接的设备分配给同一操作系统。在必须共享的情况 下，资源分配表404存储表示总线上的资源(地址空间、中断线和I/O端 口)的分配的描述符数据，以表示哪个操作系统具有哪些资源。
本实施例的实现
最后，在步骤314，硬件资源分配程序和操作系统的代码编译为与 计算机100一起提供的可发布二进制计算机程序产品。
根据本发明的一方面可以提供的产品是开发环境产品，其包括如下 的计算机程序：所述计算机程序使得用户能够选择要使用的不同操作系 统，为各个操作系统建立并选择不同的应用程序，将该应用程序和操作 系统嵌入到可交付的产品中，并提供对操作系统的引导以及对应用程序 的可执行二进制代码的启动。这基于并类似于可以从www.jaluna.com获 得的C5开发环境。
本实施例在引导和初始化期间的操作
参照图5，如下地执行根据本实施例的引导和初始化处理。
在开始供电时执行存储在ROM 106中的自举程序(“trampoline”) 4022，这启动程序4024，程序4024将硬件资源分配程序400的其余部分 安装到存储器中并将其启动，作为自变量传递描述系统映像构造的数据 结构(如下所述)。
硬件资源分配程序对可用于系统控制台的串行线进行初始化。然后， 该硬件资源分配程序从关键操作系统开始依次为各个操作系统分配存储 器空间(操作系统环境)。因此硬件资源分配程序用作第二级系统内核引 导加载程序。
然后，各个操作系统内核经过其自己的初始化阶段，在资源分配表 404中的其余资源中选择该操作系统独有的资源，并启动其初始服务和应 用程序。
图6表示构成系统映像的存储器地址分配的示例。当编译硬件资源 分配程序和操作系统时，分配存储器内的位置。存储器中的这些位置的 集合限定了图6所示的系统映像。该系统映像包括：第一存储区602，硬 件资源分配程序位于该存储区；第二存储区604，实时操作系统位于该存 储区；第三存储区606，次要操作系统位于该存储区；以及本实施例中的 第四存储区608，包含次要操作系统(Linux)的根文件系统的RAM盘 位于该存储区。
该系统映像存储在永久性存储器(例如，用于诸如移动电话或PBX 的典型实时装置的只读存储器)中。其余存储区可用于分配给各个操作 系统，作为该操作系统可以在其中加载和运行应用程序的环境。
对操作系统上下文的存储器分配
在引导时，各个操作系统随后对补充的存储器部分进行分配，以满 足其自身构造需要的总大小。一旦分配给了操作系统，就使用该操作系 统本身的物理存储器管理方案来管理存储区。该操作系统忽略所有其他 存储器。
虚拟存储器分配
对各个操作系统分配独立的虚拟存储器空间，以确保多个操作系统 不会彼此干扰或者与硬件资源分配程序干扰。对各个操作系统的用户地 址空间(即，范围)和管理者地址空间(即，范围)各自分配不同的存 储器管理单元(MMU)上下文标识符(ID)，这使得能够区分具有交叠 地址的不同虚拟存储器空间。在编译各个操作系统时向各个操作系统分 配MMU上下文ID(图3的步骤314)。
该方案避免了当硬件资源分配程序在不同的操作系统之间进行切换 时刷新转换高速缓存(translation cash)(TLB)的需要，该刷新会花费额 外的时间。相反地，通过存储当前运行的操作系统的MMU上下文ID、 并调回所切换的两个操作系统的先前存储的MMU上下文ID，从而实现 不同操作系统之间的切换。
对输入/输出设备的分配
如上所述，分配表404表示向各个操作系统唯一地分配了的哪些设 备。此外，表404表示向这些设备独占地分配了哪些输入/输出资源(直 接存储器存取(DMA)设备、输入/输出端口、中断等)，因此使得可以 直接使用这些资源而没有任何冲突。通常，许多设备是双份的，所以这 样可以显著减少潜在的冲突。
该分配基于操作系统构造方案(例如，在C5的情况下是在设备树中 指定的设备)。在引导时按照引导顺序将它们分配给操作系统，从而关键 操作系统可以第一个选择表404中的可用设备，而次要操作系统依次接 收在其余设备中对它们的分配。当各个操作系统初始化时，检测这些设 备的存在，并对它们使用其原有的驱动程序而不与硬件资源分配程序进 行交互。
次要操作系统的“热”重启
根据本实施例，可以在其他操作系统继续运行的同时重启次要操作 系统(例如，因为崩溃而重启)。因为系统资源的独立，所以次要操作系 统的崩溃不会干扰关键操作系统(或其他次要操作系统)的正在进行的 操作，并且该次要操作系统的重启也不会干扰关键操作系统(或其他次 要操作系统)的正在进行的操作。
在本实施例中，对硬件资源分配程序的系统“停止”和“启动”陷 阱调用有助于从关键操作系统内关闭和重启次要操作系统。此外，硬件 资源分配程序在引导时将原始系统映像的副本保存在硬件资源分配程序 分配的存储器内的永久性存储器中。作为示例，如下地对本实施例中的 热重启进行管理：
在初始启动时，硬件资源分配程序保存次要操作系统存储器映像的 副本。
关键操作系统包括用于周期性地监视次要操作系统的运行(例如， 通过设定超时并等待由在次要操作系统中运行的对等驱动程序触发的事 件，以检查它们的继续操作)的软件看门狗驱动例程。
如果关键操作系统检测到次要操作系统出故障或停止，则其对硬件 资源分配程序触发(该次要操作系统的)“停止”陷阱调用、然后触发(该 次要操作系统的)“启动”陷阱调用。
然后，硬件资源分配程序恢复所保存的该次要操作系统映像的副本， 并从存储器中重新引导它，以重新启动。可以发现，在对实施例进行测 试时，Linux次要操作系统可以在几秒钟内从锁定状态重启。
在其他方面中，热重启基于在Chorus操作系统中可用的热重启来进 行，例如在以下文献中所述：
可以从http：//www.jaluna.com/developer/papers/CSI-TR-96-34.pdf获得的 “Fast Error Recovery in CHORUS/OS.The Hot-Restart Technology”，Abrossimov，F.Hermann.J.C.Hugly等人，Chorus Systems Inc. Technical Report，1996年8月，14p。
运行时的操作
下面将更详细地描述在安装和引导之后本实施例的操作。
在已引导和初始化之后，实时操作系统运行一个或多个应用程序207 (例如UDP/IP栈——UDP/IP表示通用数据报协议/互联网协议)，并且次 要操作系统运行若干个应用程序208a、208b(例如，字处理程序和电子 表格程序)。实时操作系统微内核201和次要操作系统内核202通过硬件 资源分配程序接口与硬件资源分配程序进行通信，该硬件资源分配程序 接口包括：
·表示操作系统上下文的数据结构(即，需要被保存和恢复以切换 到该操作系统的状态变量组)，以及硬件库(repository)；
·在操作系统环境中执行的函数组；以及
·在硬件资源分配程序环境中执行的陷阱调用例程组。
如果操作系统都不需要处理器时间(例如，都已经达到“等待”状 态)，则硬件资源分配程序400切换到关键操作系统的空闲线程，其中其 等待中断或事件。因此，可以由关键操作系统的服务例程立即对中断进 行处理，而无需首先切换到关键操作系统。
在某些情况下，将产生中断或事件。例如，可能在数据端口接收到 分组，导致中断，以使所述分组可以由执行UDP/IP栈的实时操作系统进 行处理。另选的是，用户可能操纵键盘或鼠标，导致中断，以操作次要 操作系统202的GUI从而与字处理应用程序208进行交互。另选的是， 系统时钟可能指示已经过了预定时间，并且应该开始重新执行应用程序 或者应该执行操作系统功能。
然后，关键操作系统服务例程如下所述地对中断进行服务。
中断和事件处理
如果不是已经在关键操作系统中，则硬件资源分配程序中断处理程 序412调用操作系统切换程序408以切换至关键操作系统，然后中断处 理程序例程412调用关键操作系统201中的中断服务例程(ISR)。如果 该中断针对关键操作系统，则因为其来自唯一分配给关键操作系统的设 备或者因为其来自共享设备并具有特定的预定值，所以关键操作系统ISR 采取处理中断所需的动作。如果该中断不针对关键操作系统，则将控制 传递回硬件资源分配程序。
关键操作系统到次要操作系统的切换
参照图7，对于该示例，系统正在执行在关键操作系统201上运行 的应用程序207a的线程702。
如果产生了中断，则关键操作系统中断服务例程704进行中断服务。 在结束时将控制传递回线程702和由关键操作系统201的调度程序执行 的任何其他线程。当完成对所有线程的处理时，关键操作系统完成执行， 它调度其“空闲”线程。因此，关键操作系统中的“空闲”陷阱例程向 硬件资源分配程序400发出“空闲”陷阱调用。然后，硬件资源分配程 序执行进行以下处理的例程：
·如果中断处理程序412当前具有一些所存储的虚拟中断，则中断 处理程序412将这些虚拟中断转发给次要操作系统。
·硬件资源分配程序操作系统调度程序410选择要执行的次要操作 系统202。OS切换程序408随后将当前上下文(通常为处理器 MMU和状态寄存器、指令和堆栈指针)保存在关键OS上下文 存储区706中。其随后获取所存储的次要操作系统202的执行上 下文708，并将它们写到相关的寄存器中。
·如果存在针对相关的次要OS的虚拟中断，则中断处理程序412 调用次要操作系统内的用于对中断进行服务的相关中断服务例 程710，然后在完成时返回执行次要操作系统退出处的线程712。
如果中断处理程序412当前不具有未处理的中断，则操作切换程序 408的硬件资源分配程序使用存储在所恢复的操作系统上下文内的程序 计数器值，使得次要操作系统在其退出处(在本示例中为线程712处) 重新开始执行。
因此，在关键操作系统201执行了某一功能(对其自己的应用程序 或服务进行服务，或者对针对另一操作系统的中断进行服务)之后，硬 件资源分配程序将控制传递回如调度程序410所确定的下一个次要操作 系统202。
在中断时次要操作系统到关键操作系统的切换
参照图8，下面将公开从次要操作系统转移到关键操作系统的处理。 在这种情况下，系统正在执行在关键操作系统202上运行的应用程序208a 的线程712。
当产生了硬件中断时，硬件资源分配程序启动OS切换程序，以将 次要操作系统上下文保存在上下文存储区708中。硬件资源分配程序然 后切换到主要操作系统201，从上下文存储区706恢复状态变量的值，并 调用主要操作系统201的中断服务例程704。在对中断进行服务之后，主 要操作系统201的调度程序可以将控制从ISR 704传递回先前正在执行的 任何线程704(或要执行的线程)。
当对ISR和所有线程进行了处理时，主要操作系统201将控制传回 硬件资源分配程序，该硬件资源分配程序以上面参照图7所述的方式从 主要操作系统201进行切换(将状态变量保存在上下文存储区706中)， 并切换到所选择的次要操作系统201(从上下文存储区708获取状态变 量)。
操作系统间的通信——虚拟总线418
在各个操作系统中，虚拟总线例程与虚拟总线驱动程序协作。其仿 效连接操作系统的物理总线，类似于插入到Compact PCI(cPCI)背板中 的cPCI板。各个操作系统都具有用于该虚拟总线上的虚拟总线桥设备的 驱动例程，使得操作系统及其应用程序可以通过任何期望的协议(从原 始数据传输到完全IP协议栈)进行通信。
硬件资源分配程序虚拟总线基于上面已经讨论过的共享存储器和系 统交叉中断原理。具体地说，虚拟总线例程418仿效C5 buscom DDI：限 定虚拟总线桥共享设备的syscom，使得能够在虚拟总线上导出(共享) 存储器并触发对其他操作系统的交叉中断。
在各个次要操作系统中，各个虚拟总线驱动程序在启动时在硬件资 源分配程序硬件库中生成这种虚拟总线桥。这样，其导出(共享)其专 用存储器的区域，并提供了在其主机系统内产生中断的方法。
这样，第一操作系统的虚拟总线驱动程序通过以下处理向第二操作 系统发送数据：
·写入到由第二操作系统的对等虚拟总线驱动程序导出的存储器 中，然后；
·触发交叉中断以通知第二操作系统中的对等总线驱动程序可获得 数据。
在相反(输入)方向上，虚拟总线驱动程序在接收到表示这种数据 已存储在其自己的导出存储器区域中的交叉中断时，向上游传播输入数 据(以由其针对的应用程序或例程使用)。
参照图9a，要与在同一操作系统202上运行的另一应用程序208b 进行通信的应用程序208a可以通过该操作系统来实现该操作。要与在一 个操作系统202上运行的另一应用程序208b进行通信的在不同操作系统 201上运行的应用程序207b通过使用其操作系统的API向虚拟总线写入 数据来进行该操作，其操作系统使用虚拟总线驱动例程将该数据传递给 另一操作系统202，该另一操作系统将该数据从其虚拟总线驱动程序传递 给应用程序208b。
参照图9b，将该结构转换为其中第一和第二操作系统在不同的计算 机100、101上运行的结构所需的变化很小；仅仅需要改变操作系统所使 用的驱动程序，以使得它们使用用于真实总线103的驱动程序而不是虚 拟总线驱动程序。因此，使得该系统更独立于该系统在其上进行操作的 硬件。
通过硬件资源分配程序虚拟总线进行通信是应用程序可以使用的， 而且也可以由操作系统内核内部使用，从而它们可以在实现在多个操作 系统之间分配的服务时进行协作。这种“智能”分配的服务包括用于(上 述的)系统热重启的软件看门狗，或者分布式网络协议栈。
EP 1054332专利使用信号量(sernaphore)锁来使对公共通信存储器 的访问同步。这种锁引入了RT与GP操作系统之间的额外的依赖性。在 本实施例中，使用无锁通信协议而避免了该依赖性。
调试
在优选实施例中，硬件资源分配程序具有第二操作模式，其中该硬 件资源分配程序用作调试代理。
根据本实施例，在该第二模式下，硬件资源分配程序可以通过串行 通信线路与在另一机器(“主”机)上运行的调试软件工具进行通信。
这种调试工具提供高级图形用户接口(GUI)，以对硬件资源分配程 序进行远程控制。使用硬件资源分配程序虚拟化的异常机制来拦截所定 义的异常。然后用户可以构造并控制在处理器异常的情况下硬件资源分 配程序如何动作，并且还显示机器和系统状态，以使得能够诊断代码或 其他系统错误或问题。
用户可以选择一个或更多个这种处理器异常作为从操作系统到硬件 资源分配程序的陷阱调用的基础。基于所选择的异常，当在执行期间产 生各个异常时，操作系统停止，并对硬件资源分配程序执行陷阱调用， 然后该硬件资源分配程序保存当前上下文并使得能够与主机上的调试工 具进行交互。然后用户可以使得显示状态变量(例如堆栈指针、程序和 地址计数器)的当前状态和/或所选择的存储器块的内容。用户可以指定 在要调试的特定操作系统中应该俘获的给定类型的异常，或者可以指定 在任何操作系统中都应该在它们出现的任何时候将其俘获。作为响应， 仅在一个操作系统或在所有操作系统中实现陷阱调用。用户也可以指定 是在重新开始执行时将给定类型的异常正常地转发给系统还是简单地将 其忽略。
因为硬件资源分配程序在其自己的环境中执行，所以与在操作系统 内可以进行的调试相比，其能够对该操作系统进行更多的调试。重要的 是，在用作调试代理的硬件资源分配程序与所调试的系统之间没有共享 代码。这例如使得能够调试甚至内核低级代码，例如异常向量或中断服 务例程。
根据本实施例的总体(主机/目标)调试架构的一些其他方面与在以 下文献中描述的用于Chorus和C5调试系统的情况相似，所述文献是由 Jaluna发表的“C51.0 Debugging Guide”，可以从 http：//www.jaluna.com/doc/c5/html/DebugGuide/book1.html获得。
安全架构
应该清楚的是，上述实施例给出了安全架构的坚实基础。这是因为 用户通常在次要操作系统上运行不安全的应用程序，该次要操作系统与 指定的系统资源隔离开来，从而只能通过硬件资源分配程序(和主要操 作系统的驱动程序)对这些系统资源进行访问。因此，可以在主要操作 系统上运行安全应用程序，其例如执行加密/解密；使得能够访问加密文 件；管理、存储并提供密码和其他访问信息；管理并记录对版权材料的 访问和复制。在次要操作系统上运行的应用程序不能访问并非分配给该 操作系统的系统资源，并且，在操作系统按不同的存储器上下文运行(即， 使用指向不同空间的不同寻址指针)的情况下，在次要操作系统上运行 的应用程序不能用于干预在主系统上运行的应用程序从而削弱其操作的 安全性。
以下是对具体的优选实施例的描述。
1总体介绍
本文献描述了 ARM架构上的Jaluna超微内核环境。在我们早先的 文献Jaluna-2：A Multi-System Programming Environment(JL/TR-02-80.03) 中已经描述了Jaluna超微内核设计的一般原理。而本文献关注于超微内 核实现的ARM具体方面，具体来说，关注于作为超微内核环境的基石的 超微内核执行程序。
本文献描述了：如何使用ARM处理器架构以实现超微内核执行程 序，该超微内核执行程序能够运行多个独立的操作系统，这些操作系统 在它们之间并行地共享中央处理器(CPU)以及存储器管理单元(MMU)。
本文献还描述了超微内核执行程序如何处理硬件中断。具体来说， 本文献描述了用于拦截硬件中断并向主要操作系统转发硬件中断的机制 和提供给次要操作系统的软件中断机制。
注意，在本文献中，我们假设超微内核运行在单处理器计算机上， 因此，这里不涉及与对称多处理器(SMP)架构有关的方面。
2概述
2.1虚拟地址空间
如果在ARM架构的给定实现上存在MMU，则所有操作系统和超微 内核都总是在虚拟地址空间中运行，换句话说，总是使能MMU。注意， 其中执行超微内核代码的存储器上下文可能随时间而变化。另一方面， 超微内核不需要MMU，它在没有MMU的情况下也可以支持ARM处理 器。在此情况下，所有操作系统和超微内核都在物理地址空间中运行。
在本说明中，术语“存储器上下文”表示硬件地址转换树，由系统 控制协处理器(CP15)中的转换表基础寄存器来执行根目录表。
通常，支持用户模式保护的操作系统创建多个存储器上下文(每个 用户进程一个)以使得能够处理专用用户虚拟地址空间。内核每次从一 个用户进程切换到另一个时都改变存储器上下文。另一方面，连同用户 地址空间一起，操作系统内核还对在所有存储器上下文中复制的唯一管 理员地址空间进行处理。用户虚拟地址和管理员虚拟地址在ARM架构上 永远不交叠。
如果不存在MMU，则操作系统在所有进程之间共享同一地址空间， 因此不需要进行存储器上下文切换。在此情况下，我们可以说该操作系 统针对管理员空间只使用一个存储器上下文。
管理员地址空间映射可以是静态的或动态的。静态映射是在系统初 始化时创建的，它通常(整体地或部分地)对可用物理存储器进行映射。 这种映射也称为一对一映射或内核虚拟(KV)映射。具体地说，KV映 射通常覆盖操作系统内核代码、数据以及bss段。动态映射是在运行时创 建的，用以动态地访问装载的内核模块或动态分配的(非连续)存储器 块。
当超微内核调度了在CPU上运行新的操作系统时，自然应当对存储 器上下文(转换表基础寄存器)进行切换。ARM架构只支持虚拟高速缓 存，从而避免存储器上下文切换时的代价非常高的高速缓存刷新(由于 高速缓存混叠现象，高速缓存刷新可能是必要的)，我们决定要求所有 KV映射都使用相同的转换规则。换句话说，在所有操作系统的所有KV 映射中，物理存储器位置的管理员地址应该是相同的。它应当使用相同 的访问和高速缓存属性。可以说，所有操作系统都共享相同的管理员地 址空间(但是不共享转换树，转换树可以是不同的)。各个操作系统在该 管理员空间中的专用时隙中运行。注意，当不存在MMU时，所描述的 要求也是非常自然的。
在超微内核环境中区分3种存储器上下文：主要、次要以及超微内 核上下文。
主要存储器上下文是主要操作系统内核当前使用的存储器上下文。 注意，在主要操作系统支持用户地址空间的情况下，主要内核可能使用 多个存储器上下文，但是，如上所述，管理员地址空间在所有这种上下 文中都是相同的。由于超微内核并不关心用户空间映射，因此从超微内 核角度来看，主要存储器上下文是唯一的，并且主要存储器上下文包括 由主要内核建立的静态和动态管理员映射。
次要存储器上下文是次要操作系统内核当前使用的存储器上下文。 它类似于主要存储器上下文。从超微内核角度来看，(对于给定的次要内 核来说)次要存储器上下文是唯一的，并且它包括由次要内核建立的静 态和动态管理员映射。
我们要求所有的操作系统映射超微内核拥有的物理存储器，因此它 们可以直接调用超微内核(即，不需要改变执行模式和存储器上下文的 陷阱或其他特殊指令，见2.2部分)。这样，它们还可以访问由超微内核 导出的数据结构(操作系统上下文，见2.3部分)。
每个操作系统都应当能够在接收到来自通信机制实现的对应请求时 对其他操作系统拥有的一些物理存储器进行映射。
由超微内核本身来建立超微内核存储器上下文。该上下文对所有操 作系统拥有的所有存储器组以及合成的系统映像进行映射。主要在超微 内核初始化阶段使用该上下文。
注意，所有考虑的存储器上下文都应当使用相同的转换规则。
图1示出了主要、次要以及超微内核存储器上下文的示例。在该示 例中，物理存储器的大小是128兆字节。所有操作系统和超微内核都使 用从0xc0000000开始的移位一对一(KV)映射(与Linux内核一样)。
2.2超微内核调用和先占
通过函数调用显式地调用超微内核，或者通过中断/异常处理程序隐 式地调用超微内核。在前一情况下，我们说操作系统内核调用超微内核。 在后一情况下，我们说超微内核先占操作系统。强调这样一点是重要的： 总是从在管理员地址空间中运行的具有特权的操作系统代码来调用超微 内核。另一方面，超微内核可以先占操作系统内核本身以及在内核控制 下运行的用户进程。
一旦引导了合成系统映像，就首先激活超微内核，然后其开始执行 主要操作系统内核和次要操作系统内核。一旦完成了初始化阶段，超微 内核就扮演被动角色。这意味着由显式地调用超微内核的主要和次要内 核或者由外部生成的同步事件(即异常)和异步事件(即中断)来驱动 在超微内核中执行的代码。
在ARM架构上，从主要操作系统和次要操作系统用以进行超微内 核调用的机制几乎相同。在两种情况下都是间接的函数调用。另一方面， 超微内核按不同的方式先占主要操作系统和次要操作系统。
在执行环境方面，超微内核相当接近于主要操作系统内核。它常常 使用相同的存储器上下文，并且有时使用相同的管理员堆栈。这样，超 微内核与主要操作系统大致具有相同的可用性。另一方面，在次要操作 系统与提供免受次要内核故障影响的某些保护功能的超微内核之间存在 屏障。然而，注意，这种保护并不是绝对的，次要内核仍然能够使主要 内核以及超微内核崩溃。
2.2.1主要调用
主要操作系统内核通过简单的间接调用来调用超微内核。该调用不 会切换存储器上下文。
2.2.2主要先占
实际上，ARM架构上的超微内核的当前实现永远不会先占主要操作 系统。可以使用主要操作系统先占来实现操作系统之间的FPU共享的懒 惰策略。
2.2.3次要调用
次要操作系统内核通过简单的间接调用来调用超微内核。超微内核 本身在必要的情况下对存储器上下文和执行堆栈进行切换。
2.2.4次要先占
为了能够先占次要操作系统，超微内核将它自己的低层处理程序安 装在处理器异常表中。当次要操作系统被中断先占时，这些低层处理程 序跳到超微内核代码。注意，存储器上下文仍然不变，直到当超微内核 调度另一操作系统在CPU上运行时执行了显式切换。
2.3操作系统上下文
可以将超微内核数据分成两类：全局数据和每操作系统的数据。全 局数据保持全局超微内核状态(例如超微内核转换树)，而每操作系统的 数据保持与给定的主要或次要操作系统内核相关联的状态。也将每操作 系统的数据称为操作系统上下文。
实际上，超微内核对每操作系统保持两个数据结构。第一数据结构 是操作系统上下文本身。它是公用的，从任何操作系统都可以看到并且 充当超微内核接口的一部分。所有的操作系统上下文都放置在超微内核 拥有的专用存储器组中。在与超微内核接口有关的其他部分中对操作系 统上下文进行详细描述。
第二数据结构是为超微内核而设置的。它包含由超微内核执行程序 内部地使用的每操作系统的信息。
3超微内核执行程序接口
本章描述导出到主要操作系统内核和次要操作系统内核的超微内核 执行程序接口。这种接口包括在内核与超微内核之间共享的数据(即可 见操作系统上下文)以及超微内核方法。注意，超微内核接口是操作系 统角色特定的，并且(严格地说)对于主要内核和次要内核来说是不同 的。另一方面，这两个接口之间存在相当大的交集，可以根据操作系统 角色对这两个接口进行独立的描述。
3.1操作系统上下文
图11例示了操作系统上下文。
所有操作系统上下文(主要操作系统上下文和次要操作系统上下文) 都具有固定长度并被放置在按操作系统id进行索引的表中。注意，在操 作系统上下文中，通过物理地址进行所有的外部引用。操作系统必须(根 据KV映射)将这种物理地址转换成虚拟地址以访问所引用的数据结构。 该图示出了只具有两个内核的结构：主要内核和次要内核。
待处理VEX和已使能VEX字段反映虚拟异常(VEX)的当前状态。 在本文献中连同次要操作系统内核执行模型一起对虚拟化异常机制进行 进一步详细描述。
标签字段是所谓的标签列表。它包含引导信息并由引导装载器给出。 注意，在所有操作系统上下文中都对超微内核环境中的标签列表进行了 虚拟化和复制。在其他标签中，标签列表结构包含指定引导时间参数的 引导命令行。这些参数是由引导装载器给出的，或者是通过超微内核环 境变量来传递的。该命令行是操作系统特定的。超微内核对初始命令行 进行解析，以创建只包含与操作系统有关的参数的操作系统特定命令行。
RAM信息字段指向RAM描述表。RAM描述表是由所有操作系统 内核共享的全局数据结构。它描述RAM资源在操作系统之间是如何分配 的。
dev信息字段指向目标板卡上存在的设备描述符的列表。由主要操作 系统对它进行创建和管理。它描述了设备在操作系统之间是如何分配的 (设备不能被不同操作系统共享)。次要操作系统使用该列表来注册关闭 函数，在次要操作系统重启过程中可能调用该关闭函数。
VIL字段是待处理硬件中断的FIFO列表。每个条目都包含中断ID ——小整数。通常，基于ARM的板卡使用大量的不同中断源(通常大于 64个)。因此决定将待处理中断组表示为列表而非位掩码。实际上超微内 核本身永远都不会使用该字段。将它放置在这里是为了简化主要操作系 统和次要操作系统中的中断管理代码。超微内核只使用待处理VEX和已 使能VEX字段中的中断VEX位来进行中断管理。
待处理XIRQ字段是对于待处理交叉中断的表的引用。通过操作系 统id对该表进行索引。每个条目都对应于每个操作系统的32个可能交叉 中断。超微内核本身不使用该表。上下文结构引用该表，以辅助主要操 作系统和次要操作系统进行交叉中断交换。只有一个专用于交叉中断传 递的虚拟异常——交叉中断VEX。待处理XIRQ表使得可以将交叉中断 的数量扩展到32个(每个交叉中断源一位)。交叉中断位由源操作系统 (即，发送该交叉中断的操作系统内核)置位，并由目的地操作系统(即， 接收该交叉中断的操作系统内核)复位。
ID字段包含唯一的操作系统标识符。该字段是只读的。将标识符0 分配给超微内核本身，将标识符1分配给主要操作系统内核。操作系统 标识符指定超微内核接口中的操作系统。例如，使用操作系统标识符来 对分配给给定内核的资源(例如，RAM描述表中的存储器块)加标签。
操作系统上下文的最后部分指定超微内核接口方法的地址。它们是 KV映射中的地址，因此不必进行任何额外的转换就可以使用它们来调用 超微内核。回忆一下，所有的KV映射都应当使用相同的地址转换规则。
注意，超微内核对于主要操作系统和次要操作系统导出不同的函数。 例如，当主要操作系统和次要操作系统调用idle方法时，它们实际上调 用两个不同的超微内核函数。
3.2超微内核方法
超微内核提供了两组方法：控制台I/O操作和执行程序操作。控制 台I/O组使得内核可以向超微内核控制台串行线发送字符并从超微内核 控制台串行线接收字符。本文献不对控制台I/O方法(其或多或少地是通 用的)进行具体阐述，而是关注于ARM架构所特有的执行程序方法。
3.2.1安装异常处理程序
在RAM架构上，异常表是唯一的，位于地址0x00000000或地址 0xffff0000处。在超微内核环境中，将该异常表虚拟化，因此操作系统应 当调用该超微内核方法而不是将异常向量直接安装到ARM异常表中。将 异常号(即，未定义指令、预取异常中止、数据异常中止或软件中断) 以及异常处理程序地址作为参数传递。
将异常处理程序地址存储在操作系统上下文中。超微内核稍后可以 使用该异常处理程序地址，从而以最小的额外间接调用开销来直接引发 对操作系统的对应异常。
在RAM架构上，异常表不包含异常处理程序的地址，而是对每个 异常包含一个处理器指令。使用该指令来跳到实际异常处理程序。在超 微内核环境中，我们跳到由超微内核本身提供的非常小的序码(prologue code)。它从当前操作系统上下文读取异常处理程序地址并跳到该地址。 将当前操作系统上下文指针保持在序码可以容易地访问的全局变量中。 每当调度新的操作系统内核在CPU上执行时，超微内核都对该变量进行 更新。
这样，在与在本地情况(执行模式和寄存器内容)相同的执行环境 下调用异常处理程序。注意，超微内核序码对于未定义指令、预取异常 中止以及数据异常中止处理程序擦除堆栈指针寄存器组。将软件中断处 理程序的堆栈指针寄存器组保持原样。
3.2.2安装中断处理程序
使用该超微内核方法来安装直接和间接中断VEX处理程序。将其地 址作为参数传递。
直接中断处理程序类似于异常处理程序。仅由主要操作系统当其在 CPU上运行时使用这些直接中断处理程序来处理硬件中断。在与本地情 况(执行模式和寄存器内容)相同的执行环境下调用这些直接中断处理 程序。
由超微内核来调用间接中断处理程序以处理由其他操作系统内核转 发的中断。与直接中断处理程序相比，在稍微不同的执行环境下调用间 接中断处理程序。在本文献中将进一步对它们进行详细讨论。
3.2.3安装交叉中断处理程序
超微内核支持在真实CPU上并不存在的其他虚拟异常。它是交叉中 断VEX。它是操作系统间通信的基石。交叉中断非常类似于普通中断， 但是它是由操作系统而非硬件设备引发的。
使用该超微内核方法来存储对应的交叉中断处理程序。将在与间接 中断处理程序相同的执行环境(执行模式和寄存器内容)下调用它。
3.2.4发布交叉中断
使用该超微内核方法来在目的地操作系统上引发交叉中断VEX。它 还在待处理XIRQ表中设置对应位。将目的地操作系统id和交叉中断号 作为参数传递。
3.2.5空闲
超微内核提供了必须由操作系统内核在空闲循环内调用的空闲方 法。它通知超微内核进行调用的操作系统内核没有事情可做，直到下一 中断。
空闲方法调用导致系统切换到下一个准备运行的次要操作系统内核 (如果有的话)，或者当所有次要操作系统内核都为空闲时导致从主要空 闲方法返回。
超微内核对主要空闲方法提供了两种不同实现：无状态的和有状态 的。当从无状态空闲方法返回时，擦除所有寄存器。当从有状态空闲方 法返回时，保持永久性寄存器(r1到r13)。
空闲方法的正确实现取决于主要操作系统空闲循环实现，并且可以 在对应的配置.xml文件中来选择。
3.2.6重启
超微内核提供了可以由主要操作系统以及次要操作系统调用以将次 要操作系统内核重启的重启方法。将被重启的操作系统的id作为参数传 递。
超微内核停止目的地操作系统的执行，从操作系统内核映像的副本 中恢复操作系统内核映像，最后在初始入口点启动操作系统内核的执行。
3.2.7次要停止
超微内核向次要操作系统提供该停止方法。超微内核使调用方操作 进入非运行状态以防止超微内核调度程序切换到它。
可以由上述重启超微内核方法再次启动已停止的操作系统。
4主要执行环境
基本上，主要操作系统内核在本地执行环境中执行。ARM处理器上 的超微内核实现尽量使超微内核环境对主要操作系统特性(性能、中断 等待时间、先占等待时间)的影响最小化。由于主要操作系统通常是实 时操作系统，因此，即使在同一处理器上同时运行有其他(次要)操作 系统也保持主要内核行为不变是很重要的。
4.1初始化
主要操作系统提供小蹦床程序，该程序执行加电处理器初始化、将 超微内核数据安装在RAM中(如果有必要的话)、准备初始转换树、使 能MMU(如果它存在的话)并跳到超微内核入口点。初始转换树应当对 蹦床程序和超微内核进行映射。执行模式是管理员模式，将所有硬件中 断禁用。
继而超微内核将操作系统存储器组安装在RAM中，对操作系统上 下文进行初始化，并且在使能MMU(如果存在的话)并禁用硬件中断的 情况下跳到主要入口点。执行模式仍然是管理员模式。
使用位于其数据段中的静态超微内核堆栈来执行超微内核初始化代 码。当跳到主要操作系统内核时，该堆栈仍然是有效的。尽管如此，主 要操作系统内核仍然应当尽可能快地切换到它自己的堆栈并且将来应当 永远不使用该超微内核堆栈。不仅在初始化阶段而且在运行时使用超微 内核堆栈，以如在下一章中所述地对次要调用和先占进行处理。
当跳到主要操作系统内核时，管理员模式成组堆栈指针寄存器指向 主要操作系统上下文。在主要初始化阶段的开始时将处理器中断禁用。 一旦完成了关键的初始化阶段，主要操作系统内核通常就使能中断。
在初始化阶段，主要操作系统内核通常调用超微内核方法，以建立 异常和中断处理程序。最后主要操作系统进入空闲循环并调用超微内核 空闲方法。
当第一次调用空闲方法时，超微内核认为主要操作系统内核已完全 将其执行环境初始化，它进行到后初始化阶段。
在这种后初始化阶段中，超微内核完成超微内核存储器上下文。注 意，这是主要操作系统的责任：发现所有可用物理存储器并将其注册在 由RAM信息字段指向的对应描述符中，因此超微内核可以完成其存储器 上下文。一旦完成了后初始化，超微内核就调用调度程序以切换到对运 行次要内核的就绪状态、或者在所有次要内核都空闲的情况下从主要空 闲方法返回。
超微内核要求主要操作系统内核对全局共享的数据结构(RAM描述 符和设备列表)进行初始化。必须在调用空闲方法之前执行这种初始化。 该要求是自然的，因为在该时机之后次要内核可以访问全局共享的数据 结构。
具体来说，主要内核负责对在板上可用的物理存储器进行检测并将 空闲的物理存储器块注册在RAM描述符中。
根据主要板支持包(BSP)，主要内核应当启动超微内核意识(aware) 驱动程序，尤其是中断控制器驱动程序。
4.2主要异常
基本上，超微内核不拦截当主要操作系统在处理器上运行时出现的 异常。由本地主要处理程序来处理所有编程异常。超微内核仅执行小序 码以跳到对应的异常处理程序。当移植到ARM超微内核架构时，无需修 改主要低层处理程序。
注意，由未定义指令、预取异常中止以及数据异常中止处理程序的 超微内核序码来擦除成组堆栈指针寄存器。将软件中断处理程序的成组 堆栈指针寄存器保持原样。
4.3主要中断
当主要操作系统在CPU上运行时出现了中断时，在超微内核不引入 任何附加代码的情况下调用本地低层(直接)中断处理程序。将成组堆 栈指针寄存器保持原样。
4.4转发的中断
当次要操作系统在CPU上运行时出现了中断时，将该中断转发给主 要操作系统。这种中断转发处理经过以下主要步骤：
●超微内核拦截该中断；
●将被先占的次要操作系统内核的执行挂起，然后超微内核切换到 主要执行环境；
●超微内核触发针对主要操作系统内核的对应中断。
按这种方式，(在主要执行环境中)调用对应的主要低层间接中断处 理程序以处理该中断。一旦处理了该中断，主要操作系统内核就返回到 超微内核。
在从主要间接中断处理程序返回之后，超微内核调用其调度程序， 以确定要运行的下一次要操作系统。注意，在中断之后不一定继续被先 占的次要系统。由于该中断，另一(较高优先级)次要系统可能变得准 备运行。
在ARM架构上，CPU可以在7种不同的执行模式下运行：用户、 系统、管理员、未定义、异常中止、中断以及快速中断，这些执行模式 中的5个具有其专用/成组的r13和r14寄存器。因此，理想的是，当超 微内核从一个操作系统内核切换到另一操作系统内核时，还应当切换所 有的成组寄存器。为了使操作系统切换和中断转发加速，我们决定将除 管理员寄存器组以外的所有寄存器组视为擦除式，我们还决定总是在管 理员模式下执行这种切换。
注意，如果当次要操作系统在用户模式下运行时出现中断，则中断 处理程序将保存对应的堆栈寄存器组，因为它总是保存先前的状态。如 果当次要系统在管理员模式下运行时出现中断，则操作系统自身已保存 用户模式寄存器组。
满足我们的要求的最容易的方式是修改次要操作系统异常处理程 序。它们应当总是将成组堆栈指针寄存器设定为预定义值并尽可能快地 切换到管理员模式。应当仅在完成了到管理员模式的切换时才使能硬件 中断。
对于主要操作系统运行时的CPU执行模式没有限制，因为在这种情 况下不能发生操作系统切换。
当超微内核向主要操作系统内核转发中断时，它调用主要间接中断 处理程序。在r10到r15和cpsr寄存器已保存在操作系统上下文中的情况 下在管理员模式下调用该主要间接中断处理程序。r10包含指向该上下文 的指针。注意，当超微内核向主要操作系统转发中断时，主要操作系统 由于其结构而总是处于不活动状态(即，它调用空闲超微内核方法)。
作为间接中断处理程序执行的结果，主要操作系统可以调度新任务， 因此，如果它执行无状态空闲循环(如果当在空闲状态下调用它时它不 要求中断处理程序保存所有寄存器、或者简单地切换到新任务而不需要 保存空闲循环寄存器)，则超微内核应当将所有寄存器(和仅r10到r15) 都保存在操作系统上下文中。当超微内核切换回到次要操作系统时可以 恢复这些寄存器。
如果主要操作系统执行有状态空闲循环(例如，如果将空闲循环实 现为普通最低优先级任务、并且在中断处理结束时直接调用操作系统调 度程序)，那么我们可以推迟保存r0到r9寄存器，因为它们会被主要操 作系统保存。超微内核仅在其调度不同的次要操作系统时才需要保存/恢 复它们。如果我们在超微内核环境中只运行两个操作系统(一个主要操 作系统和一个次要操作系统)，则可以完全不用进行r0到r9寄存器保存。
超微内核支持普通(非优化)中断转发(当在间接中断处理程序调 用之前保存了所有寄存器时)和优化中断转发。正确的实现取决于主要 操作系统，并且可以在对应的配置.xml文件中来选择。
5次要执行环境
基本上，除了中断管理以外，次要操作系统内核执行环境相当接近 于本地执行环境。超微内核环境对中断管理的本地机制进行修改，以使 得完全可以由其他操作系统来先占次要操作系统。移植到超微内核架构 的次要操作系统内核不再禁用处理器级的中断，而是使用由超微内核提 供的软件中断机制(即，虚拟异常)。不再由这种次要操作系统内核来直 接处理中断，而是由超微内核拦截中断并将中断转发给主要操作系统内 核。继而，主要操作系统将在必要的情况下针对次要操作系统发出中断 VEX。如果该中断VEX没有被屏蔽，则次要间接中断处理程序立即处理 该中断VEX，如果已将该中断VEX屏蔽，则将其推迟。
5.1初始化
在初始化时超微内核将次要存储器组连同主要组一起安装。另一方 面，将对次要内核的最终初始化推迟到后初始化阶段。
在该阶段时，超微内核对存储器进行分配以保持次要存储器组的副 本。然后在重启时使用这种副本来恢复次要系统的初始映像。不过次要 系统重启是可选的，可以将它禁用以减少物理存储器耗用。
类似于主要内核，在管理员模式成组堆栈指针寄存器中传递操作系 统上下文。另一方面，与主要内核不同，即使在次要内核初始化阶段期 间也使能硬件中断。显然，将对应的次要中断VEX禁用。应当指出的是， 主要系统甚至可以完全先占次要内核初始化代码。为了在次要操作系统 重启时不干扰主要操作系统，这是尤其重要的。
尽管使能硬件中断，但是当启动次要内核时禁用虚拟异常(对应于 硬件中断的虚拟异常)。因此，超微内核不会传递中断，直到在关键初始 化阶段结束时由内核显式地使能这些中断。在本文献中进一步对软件中 断屏蔽机制(基于虚拟异常的软件中断屏蔽机制)进行详细描述。
在使能MM的情况下启动次要操作系统。使用超微内核上下文作 为初始存储器上下文。将这种初始一对一映射暂时地提供给次要内核。 注意，初始化代码不应修改或永久使用该映射，相反，次要内核应当建 立其自己的KV映射并尽快切换到该KV映射。
通常，次要内核使用位于数据段中的静态初始堆栈，以执行其初始 化代码。
类似于主要内核，在初始化阶段期间，次要内核通常调用超微内核 以安装异常和中断处理程序。最后，次要内核进入空闲循环并调用超微 内核空闲陷阱。
5.2次要异常
基本上，超微内核不拦截当次要操作系统在处理器上运行时出现的 异常。由本地次要异常处理程序来处理所有编程异常。超微内核仅执行 小序码以跳到对应的异常处理程序。当移植到ARM超微内核架构时，不 必修改次要低层处理程序。
注意，由未定义指令、预取异常中止以及数据异常中止处理程序的 超微内核序码来擦除成组堆栈指针寄存器。将软件中断处理程序的成组 堆栈指针寄存器保持原样。
5.3虚拟异常
虚拟异常(VEX)是由超微内核提供的机制，其使得操作系统内核 可以将异常发布给一操作系统内核并按推迟方式传递该异常。具体来说， 在ARM超微内核架构中使用VEX机制以将硬件中断替换为针对次要操 作系统内核的软件中断。
VEX接口包括位于内核上下文中的两个字段：待处理和已使能。这 些字段只对于次要操作系统上下文有意义，但是它们被主要操作系统内 核和次要操作系统内核二者访问。
自然，在待处理(或已使能)字段中由位位置来枚举所有虚拟异常。 因此，在ARM架构上存在总共32种可能的虚拟异常(待处理和已使能 字段是32位整数值)。
在ARM架构上超微内核仅支持4种虚拟异常：中断、快速中断、 交叉中断、以及“运行中”。
下表示出了如何将这些虚拟异常映射到真实异常：   虚拟异常   描述   0   “运行中”   8   中断VEX   16   快速中断VEX   24   交叉中断VEX
虚拟异常“运行中”并不对应于任何真实异常，实际上它是超微内 核内部地使用以检测内核是否空闲的伪虚拟异常。在本文献中进一步对 这种伪虚拟异常如何工作进行详细描述。
由于在同一时间可能存在多个待处理的虚拟异常、但是每次只可以 处理它们中的一个，因此根据其编号来设置所有虚拟异常的优先级。将 最高优先级分配给快速中断VEX，而将最低优先级分配给“运行中”VEX。
通常由主要内核(其提供针对中断控制器的驱动程序)对次要上下 文的待处理VEX字段进行更新。这种驱动程序通常通过在待处理VEX 字段中对恰当位进行置位来向次要内核发布虚拟异常。
由次要内核来对已使能VEX字段进行更新以使能或禁用虚拟异常。 如果在已使能VEX字段中置位了对应的位，则使能给定的虚拟异常。使 用已使能VEX字段，次要内核执行被保护为免受中断影响的关键段。换 句话说，次要内核不再对CPSR寄存器进行操纵以禁用/使能处理器中断， 而是修改其内核上下文的已使能VEX字段。
如果给定的虚拟异常同时是待处理的和已使能的，则由超微内核来 传递该虚拟异常。超微内核刚好在跳到VEX处理程序之前复位对应的待 处理位。
注意，所有VEX处理程序实际上都是间接处理程序。在已在操作系 统上下文中保存了r10到r15和cpsr寄存器的情况下在管理员模式下由超 微内核来调用这些VEX处理程序。r10包含指向该上下文的指针。
当在ARM超微内核架构上移植次要内核时，仍然必须修改低层异 常处理程序以将取代硬件中断屏蔽机制的软件中断屏蔽机制考虑进来。 当调用中断处理程序时，超微内核将对应值写入已使能字段，从而仅仅 禁用所有虚拟异常。当运行次要操作系统时总是在处理器级使能硬件中 断，因此即使在低层中断处理程序内部也可以由主要操作系统将其先占。 按这种方式，在超微内核环境中，次要操作系统变得完全可以被主要操 作系统先占。
当虚拟异常处于禁用状态时，可以由主要操作系统内核来发布虚拟 异常。在此情况下，不将异常传递给次要操作系统内核，而是将其保持 待处理，直到再次重新使能该虚拟异常。因此，当次要操作系统内核重 新使能虚拟异常时，应当对是否存在任何待处理虚拟异常进行检查。如 果该检查是肯定的，则次要操作系统内核应当调用超微内核以处理这种 待处理虚拟异常。
大体上，次要内核在以下两种情况下重新使能虚拟异常：
●当次要内核先前禁用了虚拟异常以保护关键代码段时；
●当超微内核由于间接中断处理程序调用而禁用了虚拟异常时。
5.4超微内核再进入
大多在处理器级禁用中断的情况下执行超微内核代码，以防止再进 入超微内核。另一方面，某些超微内核调用可能耗费很长时间，因此当 执行这种长操作时超微内核必须使能中断以保持主要中断等待时间短。
存在两种类型的长超微内核操作：
●同步控制台输出
该操作持续时间取决于串行线速度。例如，在9600波特率线上，单 个字符输出可能耗时多至1毫秒。
●次要内核重启
该操作持续时间取决于从副本恢复的内核映像大小。
对于以上列出的所有操作，超微内核使能中断、因此使能从主要内 核再进入。另一方面，在使能中断时，将超微内核调度程序禁用以防止 在从主要中断处理程序返回时调度另一次要内核。换句话说，超微内核 只能(由于中断而)被主要内核先占，但是禁止从次要内核再进入。这 种限制使得超微内核可以使用次要执行环境的全局资源。
可以在主要存储器上下文中执行从次要内核发出的某些长操作。换 句话说，在执行这种操作之前，超微内核切换到主要执行上下文、然后 使能中断。一旦完成了该操作，超微内核就禁用中断并通过超微内核调 度程序返回到调用方次要内核。
还应注意，优选的是，在超微内核存储器上下文中执行频繁使用的 超微内核方法(即使它们也可以在主要存储器上下文中执行)，以避免由 到主要执行环境/从主要执行环境的切换所引入的额外开销。这种频繁操 作的典型示例为在超微内核控制台上进行的同步输出。
6调度程序
操作系统调度程序的主要作用是选择要运行的下一任务。由于超微 内核对操作系统的执行进行控制，因此超微内核调度程序选择要运行的 下一次要操作系统。换句话说，超微内核向整个系统增加了额外的调度 级。
注意，在超微内核架构中，主要操作系统相对于次要系统具有更高 的优先级，并且仅当主要系统处于空闲循环时才将CPU给予次要系统。 我们可以说主要内核是不可被先占的，并且它通过在空闲循环中调用的 空闲方法来显式地调用超微内核调度程序。一旦在运行次要系统时出现 中断，就调用主要内核中断处理程序。从主要内核的角度来看，这种中 断先占了执行空闲循环的后台线程。一旦处理了该中断并完成了所有有 关任务，主要内核就返回到超微内核，超微内核调用超微内核调度程序 以确定要运行的下一次要系统。从主要角度来看，内核就是返回到被中 断占先的后台线程。对于主要内核来说，次要的活动是透明的，并且它 不改变主要系统行为。
超微内核可以执行不同的调度策略。不过，在默认情况下，使用基 于优先级的算法。注意，在相同的优先级，超微内核使用循环调度策略。 在系统映像建立时静态地配置给定次要内核的优先级。
无论执行什么调度策略，调度程序都必须对给定次要系统是否准备 好运行进行检测。将该条件计算为内核上下文的待处理VEX与已使能 VEX字段之间的按位逻辑与操作。非零结果表示该系统准备好运行。
如上所述，待处理VEX和已使能VEX对中的每一位都表示虚拟异 常。对准备好运行准则换一种说法，我们可以说：如果存在至少一个没 有被屏蔽的待处理虚拟异常，则次要系统处于准备好运行的状态。
在通常被映射到硬件和软件(交叉)中断的所有虚拟异常中，存在 反映该内核当前是否空闲的特殊虚拟异常(运行中)。
每当次要内核调用空闲方法时，在待处理VEX字段中清零“运行中” 位，每当向次要内核传递虚拟异常时，在待处理VEX字段中置位“运行 中”位。
对于在运行的次要内核，在已使能VEX字段中通常总是置位有“运 行中”位。当启动次要内核时，超微内核置位该位，当停止次要内核时， 超微内核将该位复位。当对映射到虚拟异常的中断进行屏蔽/去屏蔽时， 次要内核永远不应将“运行中”位清零。
注意，外部代理能够通过对次要内核的内核上下文中的已使能VEX 字段进行清零/恢复来挂起/恢复次要内核的执行。该特征提供了如下可能 性：在超微内核的外部实现调度策略代理，作为主要内核任务。此外， 这还使得能够将针对次要内核的调试代理作为位于主要内核上层的任务 来运行。这种次要调试代理的优点在于：由主要操作系统提供的所有服 务都变得可以用于进行调试(例如，网络连接堆栈)，并且可以在主要操 作系统上正在运行关键任务的同时进行次要内核调试。
7交叉中断
本部分主要对与超微内核交叉中断机制有关的信息(在前面的部分 中已给出)进行巩固。
这里考虑以下两种类型的交叉中断：
●发送给次要操作系统内核的交叉中断
●发送给主要操作系统内核的交叉中断
为了向目的地次要操作系统发送交叉中断，源操作系统内核首先对 与操作系统上下文的待处理XIRQ字段指向的交叉中断表对应的位进行 置位。然后源操作系统内核将交叉中断VEX发布给目的地操作系统，目 的地操作系统对目的地操作系统上下文的待处理VEX字段中的对应位进 行置位。一旦超微内核调用交叉中断处理程序，交叉中断处理程序就检 查待处理XIRQ字段，将对应于待处理交叉中断源的位清零，最后调用 隶属于该源的处理程序。源操作系统内核和目的地操作系统内核都使用 极微指令来更新待处理XIRQ字段。注意，两种类型的源操作系统内核 (主要和次要)都使用相同的算法。
为了向主要操作系统发送交叉中断，次要操作系统内核首先对与操 作系统上下文的待处理XIRQ字段指向的交叉中断表对应的位进行置位。 超微内核立即先占次要操作系统，并调用主要低层交叉中断处理程序， 主要低层交叉中断处理程序检查待处理XIRQ字段，将对应于待处理交 叉中断源的位清零，最后调用隶属于该源的处理程序。
操作系统内核一定不能使用交叉中断号零。将该中断预留给超微内 核以通知操作系统：已启动被停止的操作系统，或者已停止正在运行的 操作系统。换句话说，交叉中断号零通知运行的操作系统：全局系统配 置已改变。每当在操作系统上下文中改变了“运行中”字段的状态时， 将交叉中断号零广泛地传送给所有运行的操作系统。
其他方面和实施例
根据以上说明，很明显，上述实施例仅为示例，还可能存在许多其 他实施例。上述操作系统、平台以及编程技术全都可以自由地改变。将 本领域技术人员显见的任何其他修改、替代以及变型都视为在本发明的 范围内，无论它们是否被所附权利要求书覆盖。为了避免疑虑，要求对 本文公开的任何和所有新颖的主题及其组合的保护。