1. 操作系统架构概述

https://en.wikibooks.org/wiki/Operating_System_Design/Kernel_Architecture

操作系统是指控制和管理整个计算机系统的硬件和软件资源，并合理地组织调度计算机的工作和资源的分配，以提供给用户和其他软件方便的接口和环境。他是计算机系统中最基本的系统软件。

1. Security Models
   

https://en.wikipedia.org/wiki/Computer_security_model

1. Access Control
   

2. Capability-based security
   

Capability-based security用一个key来访问某个对象，并且将key关联最小的访问权限。典型的例子是Linux中的文件描述符：

int fd = open(“/etc/passwd”, O_RDWR);

1. 形式化验证（Formal Verification）

https://en.wikipedia.org/wiki/Formal_verification

https://blog.csdn.net/ggjrtg/article/details/83926848

seL4宣传其是第一个完全通过形式化验证的内核。不过seL4的验证是建立在一些前提假设基础上的，并非”完全”验证。比如其假设只有CPU能访问内存，不考虑DMA存在的情况，再比如，内核中的一些汇编代码和启动代码是没有形式化验证的。

从广义上讲，形式化方法是借助数学的方法来解决软件工程领域的问题，主要包括建立精确的数学模型以及对模型的分析活动。狭义的讲，形式化方法是运用形式化语言，进行形式化的规格描述、模型推理和验证的方法。就形式化建模而言，形式化表示必须包含一组定义其语法语义的形式化规则。这些规则可用于分析给定的表达式是否符合语法规定，或证明该表达式具有某种性质。

形式化方法的出发点是数学逻辑方法，其目的是开发可靠的软件产品。从软件开发来讲，形式化方法目前并非软件开发的主流。从软件发展看，早期的软件是用于数值计算，程序语言侧重于函数和算法的描述，后来数据库的应用和数据结构逐渐变得重要。现在的软件更为复杂，因此，对象、组件、接口、通讯、开放等成为非常重要的概念。从软件工程方法来讲，有一套描述这些概念的办法，比如说用图形、表格、逻辑、自然语言等，交叉使用以描述一个系统的各个方面。因此换一个角度来考虑，我们也可以以目前常用的软件开发方法为出发点，研究怎样将这些方法形式化，使软件系统的描述精确化，以减少可能的误解所带来的问题；或以目前常用的软件开发过程为出发点，研究怎样在软件开发过程中增加一些形式化方法的应用，以提高软件的可靠性。

形式化方法可以分为形式化描述和建立在形式化描述基础之上的形式化开发。形式化的描述就是用形式化的语言(具有严格的语法语义定义的语言)做描述。形式化的软件开发，就是用形式化的语言来描述软件需求和特征，并且通过推理验证来保证最终的软件产品是否满足这些需求和具备这些特征。这样的验证当然得建立在严格的语法语义的基础之上的。在实际应用中，这是不容易做到的。形式化方法研究的目的就是希望能够提供更好的理论、方法和工具，扩大形式化方法的应用范围和使用价值。

形式化方法的意义在于它能帮助发现其它方法不容易发现的系统描述的不一致、不明确或不完整，有助于增加软件开发人员对系统的理解，因此形式化方法是提高软件系统，特别是Safety-Critical系统的安全性与可靠性的重要手段。最早的形式化方法是逻辑与逻辑推理，它的目标是使推理机械化。从广义上讲，这一目标受到许多挫折，比如说逻辑系统的不完备性(incompleteness)、逻辑系统的不可判定性(undecidability)、自动推理的难处理性(intractability)。但是在一些实际应用上，逻辑方法和自动推理还是起着非常大的作用。

形式化方法在软件开发中能够起到的作用是多方面的。首先是对软件需求的描述，软件需求的描述是软件开发的基础。比如说一般非形式化的描述很可能导致描述的不明确和不一致，如果描述的不明确和不一致将导致设计、编程的错误，将来的修改所要付出的代价就非常大了，如果导致的错误没有被发现，则影响程序的可靠和使用。形式化方法则要求描述的明确性，而描述的不一致性也就相对易于发现。其次是对软件设计的描述。软件设计的描述和软件需求的描述一样重要，形式化方法的优点对于软件需求的描述同样适用于软件设计的描述，另外由于有了软件需求的形式化描述，我们可以检验软件的设计是否满足软件的要求。对于编程来讲，我们可以考虑自动代码生成。对于一些简单的系统，形式化的描述有可能直接转换成可执行程序，这就简化了软件开发过程，节约了资源和减少了出错的可能性。另外，形式化方法可以用于程序的验证，以保证程序的正确性。对于测试来讲，形式化方法可用于测试用例的自动生成，这可以节约许多时间和在一定程度上保证测试用例的覆盖率。

形式化方法原则上就是用数学与逻辑的方法描述和验证软件。从描述上讲，一方面是系统或程序的描述，另一方面是性质的描述。这些可以用一种或多种语言来描述。这些语言包括命题逻辑，一阶逻辑，高阶逻辑，代数，状态机，并发状态机，自动机，计算树逻辑，线性时序逻辑，进程代数， π-演算， μ-演算，特殊的程序语言，以及程序语言的子集等。从验证来讲，主要有两类方法，一类是以逻辑推理为基础，另一类则以穷尽搜索为基础。逻辑推理有 natural deduction, sequent calculus, resolution 以及Hoare-logic 等方法，穷尽搜索方法统称为模型检测。这类方法与系统或程序以及系统性质的表示有很大的关系，比如说符号模型检测，其基本原理是用命题逻辑公式表示状态转换关系，用不动点算法计算状态的可达性以及这些状态是否满足某些性质。

形式化方法的应用在电路设计和协议设计上都取得了很大的成绩，但是对于软件来讲还有很多没有解决的问题。软件的描述要比电路和协议复杂，一个软件描述所包含的状态空间通常来讲可以是无限的，因此验证的难度很大。逻辑推理的不足之处在于推理的难度，对于稍微复杂的系统，自动化的推理就难以胜任。人为的推理有很大的缺点，除了费时费力外，比如说一个定理推不出来，并不能说明这个定理不成立，很可能是推理方法和策略应用不当。模型检测的好处在于它有全自动化的检测过程，并且如果一个性质不满足，它能给出这个性质不满足的理由，我们即可据此对我们的系统描述进行改进。模型检测的困难首先是它所能检测的是有限状态模型。这样对于一般软件来讲，需要有一个从任意状态到有限状态的建模过程，并且这样的一个模型的状态空间会面临组合爆炸的问题。

形式验证一般被称为形式化验证方法，是相对于传统的验证（模拟、仿真和测试）而言的。形式化验证方法的主要思路就是使用数学的公式、定理和系统来验证一个系统的正确性等。目前的形式化验证方法可以用于验证硬件系统、软件系统和其他系统，而且形式化验证的技术目前也已经发展到不但可以验证系统的功能正确性（有没有错误），而且可以验证系统的性能指标（功耗、散热、延迟等等）。形式化验证方法主要可以分为三种：定理证明、模型检测和等价性验证。定理证明的基本原理是选定一个数学逻辑体系，并用其中的公式来描述（如软、硬件）系统和系统性质刻画，然后在一定的数学逻辑（如hol逻辑）体系中依据此体系的公理、定理、推导规则和系统描述公式，看看能不能推导出系统的性质刻画公式，如果可以的话验证成功。模型检测的原理比较简单但是非常实用，它将（如软、硬件）系统建模成有限状态系统（一般成为keripke结构），系统的性质刻画用时序逻辑公式表示（CTL，LTL等），而后在此模型上来验证性质刻画的正确性，模型检测于定理证明相比是有很大优势的，他可以全自动地验证，不需要人工干预，而定理证明则在一些关键推导路径中需要数学家控制。还有一种是等价性验证，等价性验证其实是一种半形式话的技术，同前两种验证正确性的技术不同，它验证的是设计的一致性，即不同设计阶段的设计是否功能相同，这种技术中一般采用符号的方法和增量的方法，而且由于这种方法和硬件电路紧密结合，所以电路验证的一些传统方法也大量应用于此中方法中来，比如ATPG技术等。如大家使用的Synopsys的Formality本质上就是一个等价性验证器。形式化验证是非常有用的，只是国内作这一行的人太少。大家可以看看Synopsys和Cadence两家公司，它们都是从形式化验证起家的，然后转到目前流行的将设计和验证统一在一起，即”设计验证”领域。

软件形式化方法研究内容：

• 形式化语言（形式化描述、形式规约）：怎样描述软件系统及其行为模式；更好地刻画软件系统的性质，比如说，通讯、分布、开放、移动；各种语言的应用、比较，语言与语言之间的转换；开发相应的软件工具。
  
• 形式化验证（形式验证）：怎样验证软件系统符合给定的行为模式；更有效地验证软件系统的性质，比如说，自动化、速度快、内存需求少；各种方法的应用、比较；开发相应的软件工具。
  

具体来说，软件形式化方法包括以下几个主要研究方向：

(1) 基础概念：复合、抽象、重用模型、数学理论组合、数据结构及算法。需要对如何复合方法、复合规格、复合模型、复合理论、复合证明等进一步的理解；需要开发出将整体特性分解为易于验证的局部特性的有效方法；实际系统在规格和验证之前都要进行某种程度上的抽象，需要研究出评判抽象层次合理与否的方法；重用不仅可以提高开发效率，而且可以提高软件的可靠性，应当研究可重用模型和理论；许多安全关键反应式系统是数字和模拟混合的，需要连续和离散两个范畴内数学基础支撑的混杂系统理论和技术支撑；大规模、复杂软件中搜索空间是巨大的，需要研究出新的数据结构和算法。

(2) 形式化方法与面向对象方法的结合：这已经成为软件工程领域的一个研究热点，例如：Statecharts、Petri网、Z语言、VDM等，以及与面向对象方法结合产生的Objectcharts、面向对象Petri网、Object-Z、Z++、VDM++等。这方面的研究体现在两个方面：利用面向对象结构来提高形式符号的表达能力；使用形式化方法来分析面向对象的语义或提高这些标记符号的表达对象概念的能力。形式化方法和其他传统软件开发方法相结合以达到取长补短的目的，也是值得研究的课题。

(3) 工具开发：具有良好用户界面、易于学习和操作简单的形式化方法支撑工具，对于形式化方法的推广应用是大有裨益的。追求通用的完善的形式化方法及其支撑工具是不现实的，侧重于如下某一个或几个方面准则的特色方法和工具是未来研究的重点。这些准则包括：一旦开始使用之后尽早得到明显的效益；效益随着开发者的了解深入和熟练而增加；单一规格可以在软件开发生命周期的多个阶段取得效益；能和其他通用编程语言或方法交互使用；工具应当像编译器那样易于使用、输出，也易于阅读；概念和工具应当易于入门和学习掌握；软件特性分析有所侧重；支持渐进软件开发，允许部分规格和验证。此外，特定问题域的形式化方法及其工具研究也是非常重要的。

1. 操作系统的发展史
   

https://en.wikipedia.org/wiki/History_of_operating_systems

https://en.wikipedia.org/wiki/Timeline_of_operating_systems

现代所有操作系统的鼻祖可追溯到美国AT&T公司和贝尔实验室等共同开发的MULTICS（多路信息计算系统）。自那开始，整个操作系统的演化可分成以下三个阶段：

（1）Unix初始系统诞生。此时的操作系统主要面向专业人士，无可视化界面，非专业人士不可用。

（2）可视化操作系统演进。以苹果 Mac、微软Windows为代表的可视化操作系统诞生，降低了使用者门槛。

（3）开源Linux诞生与演进。全世界软件人员合力开发的免费开源操作系统的诞生和长足发展。

1. OS相关标准

   1. Portable Operating System Interface (POSIX)

在早期，Unix应用程序虽然可以在不同版本的unix操作系统之间移植相当容易，但是随着Unix系统版本的剧增以及他们的差别越来越大，不同版本的unix系统的应用程序的移植也越来越困难，为了提升应用程序在各种Unix系统环境的移植性，各机构对其进行了标准化，标准化的一个重要工作就是对每种实现必须定义各种限制进行说明。

可移植操作系统接口（英语：Portable Operating System Interface，缩写为POSIX）是IEEE为要在各种UNIX操作系统上运行软件，而定义API的一系列互相关联的标准的总称，其正式称呼为IEEE Std 1003，而国际标准名称为ISO/IEC 9945。POSIX定义了应用程序编程接口（API）以及命令行工具程序接口，以实现软件在各种Unix和其他操作系统中的兼容性。

之所以选择Unix作为标准系操作统接口的基础，部分原因是它是与厂商中立的。POSIX规范最初由用于核心编程接口的单个文档组成，但最终发展为19个单独的文档（POSIX.1，POSIX.2等）。标准化的用户命令行和脚本接口基于UNIX System V Shell。许多用户程序、服务和工具（包括awk，echo，ed）得到了标准化。 POSIX还定义了大多数现代操作系统支持的标准线程库API。 在2008年，POSIX的大部分内容被合并为一个标准（IEEE Std 1003.1-2008，也称为POSIX.1-2008）。

到2014年，POSIX文档分为两个部分：

• POSIX.1, 2013 Edition: POSIX Base Definitions, System Interfaces, and Commands and Utilities (which include POSIX.1, extensions for POSIX.1, Real-time Services, Threads Interface, Real-time Extensions, Security Interface, Network File Access and Network Process-to-Process Communications, User Portability Extensions, Corrections and Extensions, Protection and Control Utilities and Batch System Utilities. This is POSIX 1003.1-2008 with Technical Corrigendum 1.)
  
• POSIX Conformance Testing: A test suite for POSIX accompanies the standard: VSX-PCTS or the VSX POSIX Conformance Test Suite.
  

1. Single UNIX Specification (SUS)

https://en.wikipedia.org/wiki/Single_UNIX_Specification

https://www.opengroup.org/membership/forums/platform/unix

Single UNIX Specification（SUS，单一UNIX规范）是POSIX.1标准的一个超集，它定义了一些附加接口扩展了POSIX.1规范提供的功能。POSIX.1相当于Single UNIX Specification中的基本规范部分。

POSIX.1中的X/Open系统接口（X/Open System Interface，XSI）选项描述了可选的接口，也定义了遵循XSI（XSI conforming）的实现必须支持POSIX.1的哪些可选部分。这些必须支持的部分包括：文件同步、线程栈地址和长度属性、线程进程共享同步以及_XOPEN_UNIX符号常量（在图2-5中它们被加上”SUS强制的”的标记）。只有遵循XSI的实现才能称为UNIX系统。

Open Group拥有UNIX商标，他们使用Single UNIX Specification定义了一系列接口。一个系统要想称为UNIX系统，其实现必须支持这些接口。UNIX系统供应商必须以文件形式提供符合性声明，并通过验证符合性的测试，才能得到使用UNIX商标的许可证。

有些接口在遵循XSI的系统中是可选的，这些接口根据功能被分成若干选项组（option group），具体如下:

• 加密：由符号常量_XOPEN_CRYPE标记。
  
• 实时：由符号常量_XOPEN_REALTIME标记。
  
• 高级实时。
  
• 实时线程：由符号常量_XOPEN _REALTIME_THREADS标记。
  
• 高级实时线程。
  

Single UNIX Specification是Open Group的出版物，而Open Group是由两个工业社团X/Open和开放系统软件基金会（Open System Software Foundation，OSF）在1996年合并构成的。X/Open过去出版了X/Open Portability Guide（X/Open可移植性指南），它采用了若干特定标准，填补了其他标准缺失功能的空白。这些指南的目的是改善应用的可移植性，使其不仅仅符合已发布的标准。

X/Open在1994年发布了Single UNIX Specification第1版，因为它大约包含了1170个接口，因此也称为”Spec 1170″。它源自通用开放软件环境（Common Open Software Environment，COSE）的倡议，该倡议的目标是进一步改善应用程序在所有UNIX操作系统实现之间的可移植性。COSE的成员包括Sun、IBM、HP、Novell/USL以及OSF等，他们的UNIX都包含了通用商业化应用软件使用的接口，这较之仅仅赞同和支持标准前进了一大步。从这些应用软件的接口中选出的1170个接口被包括在下列标准中：X/Open通用应用环境（Common Application Environment，CAE）第4发行版（也被称为XPG4，以表示它与其前身X/Open Portability Guide的历史关系）、系统V接口定义（System V Interface Definition，SVID）第3版Level 1接口、OSF应用环境规范（Application Environment Specification，AES）Full Use接口。

1997年，Open Group发布了Single UNIX Specification第2版。新版本增加了对线程、实时接口、64位处理、大文件以及增强的多字节字符处理等功能的支持。

Single UNIX Specification第3版（SUSv3）由Open Group在2001年发布。SUSv3的基本规范与IEEE标准1003.1-2001相同，分成4个部分：基本定义、系统接口、shell和实用程序以及基本理论。SUSv3还包括X/Open Curses第4发行版第2版，但该规范并不是POSIX.1的组成部分。

2002年，ISO将IEEE标准1003.1-2001批准为国际标准ISO/IEC 9945:2002。Open Group在2003年再次更新了1003.1标准，包括了技术方面的更正。ISO将其批准为国际标准ISO/IEC 9945:2003。2004年4月，Open Group发布了Single UNIX Specification第3版2004年版，将更多技术上的更正合并到标准的正文中。

2008年，Single UNIX Specification再次更新，包括了更正和新的接口、移除弃用的接口以及将一些未来可能被删除的接口标记为弃用接口等。另外，有一些过去被认为可选的接口变成必选接口，其中包括异步I/O、屏障、时钟选择、存储映像文件、内存保护、读写锁、实时信号、POSIX信号量、旋转锁、线程安全函数、线程、超时机制以及时钟等。最终形成的标准就是基本规范的第7发行版，也即POSIX.1-2008。Open Group把这个版本和X/OPEN Curses规范的更新版打包，并于2010年作为Single UNIX Specification第4版发布。我们把这个规范称为SUSv4。

1. System V Application Binary Interface

https://wiki.osdev.org/System_V_ABI

System V (“System Five”) ABI规范包含了一系列关于调用约定，对象文件格式，可执行文件格式，动态链接语义等很多方面的规范细节。 今天，它是主要的Unix操作系统（例如Linux，BSD系统以及许多其他操作系统）使用的标准ABI。 Executable and Linkable Format (ELF)是System V ABI的一部分。

该标准是可扩展的，并且格式随着Unix供应商添加新功能而不断发展。 由于存在许多非官方的补充规范以及Unix操作系统的混乱历史，当前的情况是System V ABI已成为一系列非官方的草案规范，而没有真正的中央管理机构。

在此规范中，许多高级功能（例如动态链接）是可选的，并且加载简单的静态链接的ELF程序非常简单。该标准的早期版本非常宽泛，试图标准化软件安装包格式和X11详细信息，而今天已经忽略了这些过时的详细信息。 常见的操作系统开发工具（例如Binutils和GCC）对这个ABI有很好的支持。

1. Filesystem Hierarchy Standard (FHS)

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

文件系统层次结构标准（FHS）定义了Linux发行版的目录结构和目录内容。它由Linux基金会维护，最新版本是3.0，于2015年6月3日发布。

大多数Linux发行版都遵循FHS标准，某些发行版基本遵循该标准，但在某些方面有所不同。

1. Linux Standard Base (LSB)

https://refspecs.linuxfoundation.org/lsb.shtml

https://refspecs.linuxfoundation.org/lsb.shtml

LSB是Linux标准化基地(Linux Standards Base)的简称，目前是FSG(Free Standards Group)中最为活跃的一个工作组，于2001年首次公布。它诞生的目的是为了推进Linux二进制兼容性，即二进制程序不需要重新编译，就可以在其他发行版上运行。在许多系统中都可以使用命令lsb_release -a来获取LSB版本的详细信息。

值得注意的是，Debian在2015放弃兼容 Linux Standard Base 标准，只遵循Filesystem Hierarchy Standard (FHS) 标准，Debian开发者认为维护LSB兼容性耗费精力太多而所得好处又太少。（LSB有很多限制，并且其兼容性测试套件有很多BUG）

一直以来，Linux都试图遵守POSIX标准，因此在源代码级上已具有很好的兼容性，然而对于Linux来说，仅仅保证源码级的兼容性还是不能完全满足要求的。软件开发商不得不面临在不同硬件平台上移植应用程序的问题。如果系统生命周期长，还要投入足够资源进行技术支持。就连我们最熟悉的x86平台，发行版也多如牛毛，软件开发商不可能为每个发行版都发布一个二进制文件。这便导致了经常会有软件用户问：”这个软件运行在哪个Linux上？”的情况发生。

上面的目标根形象地描绘了LSB的使命。它的使命就是给代表自由的小企鹅量体裁衣。在给特定企鹅的体形和三维标准之后，软件开发者就可以设计并裁减出各色花样的衣服（应用程序），这样不管穿在哪只企鹅身上，都会非常合身。

为了保证应用软件开发者所开发的应用无论是在不同发行版本之间，还是同一版本的升级系统上都能正确运行，LSB在跟各大发布商咨询后，公布了描述必须支持的最小API的集合。在这个标准基础上LSB还提供了测试和工具方面的支持，使应用开发者目标一致，防止在不同的版本之间存在不必要的差异，减少在不同系统上做开发和维护的苦恼。

LSB以POSIX和SUS(Single UNIX Specification)标准为基础，并对其他领域（例如图形）中源代码的一些标准进行了扩充，还增加了对二进制可执行文件格式规范的定义，以确保Linux应用程序的源码和二进制文件的兼容性。

在POSIX标准基础上，LSB制定了应用程序与运行环境之间的二进制接口，这主要是基于以下标准：

• Single UNIX Specification（SUS）
  
• System V Interface Definition（SVID）
  
• Compilers for the Intel Itanium processor
  
• C++ABI
  
• System V Application Binary Interface(ABI)
  

LSB充分吸取了UNIX标准化努力所取得的经验和教训，不像POSIX仅仅定义了编程接口标准，而且还包含了一个二进制兼容层。它对各个库提供的接口以及与每个接口相关的数据结构和常量进行了定义，主要包含以下三个方面的内容：

1. 规范：一系列兼容应用和发行版本必须达到的内容；
   
2. 工具：一系列工具，测试和信息系统，以一种写作的方式帮助开发LSB兼容应用和Linux发行版本，并能帮助完成自动认证过程。
   
3. 认证：使用工具和规范保证平台/应用兼容的双向承诺的过程。
   

LSB是Linux操作系统的一个核心标准，它鼓励应用和平台之间的互操性。没有规矩不成方圆，有了规范才有了参考依据。规范定义了跨多个Linux发行版本的公关元素，其中包括：

• 打包和安装指导
  
• 共享库和他们的接口
  
• 配置文件
  
• 文件放置（文件系统分层标准）
  
• 系统命令
  

因为是二进制规范，LSB分别为普通和特定处理器定义相应的组件。目前支持下面的计算架构：

• x86(IA32)
  
• x86-64(AMD64/EM64T)
  
• Intel IA64（Itanium)
  
• IBM PPC 32
  
• IBM PPC 64
  
• IBM 31-bit S/390
  
• IBM64-bit zSeries
  

通过一个典型的Linux发行版本就可以提供兼容保证，这样LSB为应用程序开发商们消除了支持跨系统开发的压力，使他们编写的应用可以最终用户在自己喜欢的发行版本上使用。

上图给出了LSB环境中所包含的组件。这些组件包括开发者所需要的共享库（包括C++），文件系统层次结构(FHS)、对象文件格式、命令和工具、应用程序包、用户和组、系统初始化等所采用的规范。

为了更好地推动和制定LSB规范，项目又分成了几个子项目（也称为工作组），分别有不同的职责范围。LSB老大的头衔叫主席，他和各个子项目的领导人，以及对LSB项目有重大贡献的人组成了执行委员会。执行委员会负责LSB整体规划和推广工作。

在制定好标准开发出测试套件之后，为了区分系统或应用程序是否兼容LSB标准，FSG提供了LSB标准认证服务。任何Linux发行版厂商和应用程序开发商都可以进行Linux认证，目前提供的认证有两种：

• LSB运行环境：为平台供应商提供的LSB标准认证。
  
• LSB应用程序：为应用程序开发商提供的LSB标准认证。
  

对于平台供应商来说，经过LSB认证之后，就可以确保自己的系统所提供的服务都是标准的，任何遵守LSB标准的应用程序都可以在自己的系统上很好地运行；而对于应用程序开发商来说，意义刚好相反，即不需要担心自己的应用程序在遵守LSB标准的系统上出现可移植性问题。不仅平台供应商和应用开发者从中受益，最终的用户也尝到了甜头，他们可以根据自己的喜好来选择发行版和应用而不用锁定供应商。在LSB驱动下，Linux生态系统就这样自动催化形成了。

1. Microkernels (微内核)

   1. 概述
      

https://wiki.osdev.org/Microkernel

传统上，操作系统的”内核”是系统上运行的所有其他软件都需要的部分。因此，内核对应于可信计算基础(Trusted Computing Base ，TCB)的OS部分，这些部分的正确行为是任何其他部分正确操作的先决条件。

微内核的基本思想是最小化内核，并在TCB之外实现尽可能多的内核。内核应该只导出简单的、低级的操作，希望这些操作能够实现更高效的应用程序。这个想法可以追溯到[Per Brinch Hansen在1970年发表的<The nucleus of a multiprogramming system>]，一个好的概述可以在[J. Liedtke. Toward Real Microkernels. 1996]中找到。传统的内核是 “单结构的” ，在某种意义上说，它们在TCB内以相对非结构化的方式实现其所有功能。从软件工程的角度来看，微内核的优点是显而易见的：

• TCB变得更小，减少了由于它的错误实现而产生错误的机会。
  
• 操作系统更加模块化，因此更加灵活和可扩展性。
  
• 在TCB中以前的服务现在可能有多个不同的实现，甚至可能并发运行。
  

微内核最初受到了极大的热情，在80年代后期，在学术和商业环境中都有很多关于微内核的工作。当人们开始遇到似乎与微内核实现的灵活性和效率有关的内在困难时，最初的热情消退了:

• 对于一些频繁的操作，例如网络化，上下文切换的开销对于内核实现来说太大了。因此，微内核不像最初想象的那样有效。
  
• 支持多个基本系统服务的实现存在很大的困难，特别是当多个并发运行时。因此，微内核并不像假设的那样灵活。
  
• 通过对原始微内核理想的各种妥协克服了这些困难。几个效率关键的特性被重新引入内核，并且通过可下载的二进制代码或可信的”内核加载模块”支持向内核添加新特性。
  
• 但是，将大多数驱动程序和服务器集成回TCB，在很大程度上消除了微内核方法的好处，最终导致更复杂的单内核操作系统内核。
  

最近，在微内核理念之后出现了几种第二代实现，它们声称可以解决第一代的灵活性和效率问题。这些实现如何实现这个目标有很大的不同，以下三个具有代表性:

• L4 [J. Liedtke. Toward Real Microkernels. 1996]拥有一个非常小的微内核，并按照第一代的精神使用用户级服务器。它通过非常快速的进程间通信和灵活的内存管理方案来实现它的目标。
  
• Exokernel，是一个微型微内核，它消除了所有传统的OS内核抽象，将内核的任务简化为安全的多任务资源。
  
• SPIN采用的方法是将代码下沉到内核中，但是是以一种安全的方式，不会真正扩大TCB。
  

目前尚不清楚这些新一代解决方案是否真正适用于实际操作系统。缺少的是使用上述系统的策略构建的真实操作系统的存在，就像Chorus和Mach是使用第一代微内核策略构建的真实操作系统一样。尽管如此，上述系统的出现给微内核方法的未来带来了巨大的希望。

Nanokernel: A kernel where the total amount of kernel code, i.e. code executing in the privileged mode of the hardware, is very small.

1. 效率问题
   

在将几个微内核构建到真正的OSs中并用于实际应用之后，人们发现，当客观地测量它们的性能时，它们的性能相当差。这种低效率有几个罪魁祸首，包括:

1. 在用户模式下运行以前内核集成的服务，需要在内核或客户端使用服务时，使用(RPC)远程过程调用(用两个IPC实现)。RPC的成本比对内核的简单系统调用要高得多，大约是每RPC 200微秒，而传统的系统调用是40微秒。
   
2. 在微内核操作系统中，当运行相同的应用程序时，内存引用的成本(每个指令的内存周期，MCPI)要比宏内核操作系统高得多。原因包括:
   
   1. 合并的微内核OS代码的局部性更差。
      
   2. 系统的自身干扰，错误地缓存高速缓存行，归咎于系统的高度模块化。
      
   3. 由于操作系统的模块化程度较高，模块间的复制更多。
      
3. 微内核的”遗留”接口和实现代码不支持某些操作系统特性的有效功能。这在很大程度上是由于微内核的开发历史，它是从宏内核派生出来的，继承了它们的许多接口和实现策略。
   

上面的第一项，IPC成本，是改进微内核性能的主要工作重点，因为它比MCPI的影响要大得多。尽管如此，由于上述第三个原因，改进第一代微内核(特别是Mach)的IPC成本的尝试还不够成功。下面的表1显示了在优化IPC的大量工作之后，Mach OS的最终IPC性能。L3的工作，导致L4，最终成功打破了这一性能障碍。

值得注意的是，Mach IPC性能已经很糟糕了，在连续的RPC调用之间必须执行大约10000条指令，相对于宏内核来说，速度只降低了10%。这阻止了细粒度的客户端/服务器应用程序结构。更广泛地说，第一代内核和传统内核缺乏效率，这就限制了灵活的应用程序/操作系统结构，比如IPC支持的那些结构。

相比之下，L4和Exokernel IPCs的速度要快很多，因为它们采用的是全新的实现。这些内核能够在每400条指令中执行一次RPC调用，速度降低10%，这对于几乎所有的应用程序来说都足够细粒度。Spin内核是基于Mach的，因此分担了它高昂的IPC成本，但这可能不会对它的性能造成致命的影响，因为它采用了可扩展性的替代方法。

1. IPC

   1. Sync vs Async IPC

   2. Direct vs Indirect

1. QNX

QNX是一个分布式、可扩展、遵从POSIX规范的类Unix硬实时操作系统。QNX为微内核的架构，微内核只提供进程调度、进程间通信、底层网络通信和中断处理四种服务。驱动程序、协议栈、文件系统、应用程序等都在微内核之外内存受保护的安全的用户空间内运行，组件之间能避免相互影响，在遇到故障时也能重启。

1. AmigaOS

AmigaOS 是 Amiga 个人计算机默认的本地操作系统。在一个基础核心叫做 Exec 之上，它包括一个 Amiga 独特的硬件提取，一个磁盘操作系统叫做 AmigaDOS ，一个视窗系统叫做 Intuition 和一个图形用户界面叫做 Workbench 。它于1985年面世，是第一个提供真彩色的操作系统。成为了快速，高分辨率图形的代名词。

1. MINIX

http://minix3.org/

MINIX 3 is a free, open-source, operating system designed to be highly reliable, flexible, and secure. It is based on a tiny microkernel running in kernel mode with the rest of the operating system running as a number of isolated, protected, processes in user mode. It runs on x86 and ARM CPUs, is compatible with NetBSD, and runs thousands of NetBSD packages.

1. SPIN

http://www-spin.cs.washington.edu/

SPIN is an operating system that blurs the distinction between kernels and applications. Applications traditionally live in user-level address spaces, separated from kernel resources and services by an expensive protection boundary. With SPIN, applications can specialize the kernel by dynamically linking new code into the running system. Kernel extensions can add new kernel services, replace default policies, or simply migrate application functionality into the kernel address space. Sensitive kernel interfaces are secured via a restricted linker and the type-safe properties of the Modula-3 programming language. The result is a flexible operating system that helps applications run fast but doesn’t crash.

We have used SPIN to implement a wide variety of demanding applications and services. For instance, the SPIN Web server executes entirely in the kernel address space. This allows it to access the network and the local disk with low latency. The Web server application, as well as the file system interface, entire network protocol stack, and device infrastructure are all linked into the system after it boots.

1. L4

http://l4hq.org/projects/kernel/

https://github.com/seL4/seL4

L4是J. Liedtke和他的团队在1995年开发的，是L3的直接后代，L3是第一代微核。L4的从头开始开发，加上它的小尺寸和简单的接口，使它能够摆脱第三种”遗留”代码类型的微内核问题。

L4 Kernel Family Tree:

L4基于微内核是处理器相关的理论，即像代码优化器一样，微内核本身就不能移植，尽管它们提高了整个系统的可移植性。L4提供了三个抽象,地址空间、线程和IPC，并且只实现了七个系统调用。L4中的线程是用户级的，但是内核支持通信和地址空间管理。

L4微内核提供了实现物理内存管理和各种保护方案的基本机制。基本思想是支持内核之外的地址空间的递归构建：

初始地址空间表示物理内存，并由初始内存服务器拥有。虚拟页面的所有者可以使用L4提供的操作，将其所有权转移到(grant)或与(map)共享，这是一个同意的接收进程。所有者还可以从接收者的地址空间中删除任何共享页面(demap)，而不需要在两个进程之间达成任何协议。

此功能允许实现内核之外的内存管理和分页。映射和解调足以在微内核之上实现内存管理和分页。授予仅在特殊情况下使用，以避免双重簿记(bookkeeping)和地址空间溢出。为了验证进程一致性，采用IPC实现内存管理和分页，进一步强调了快速IPC的必要性。

1. IPC实现
   

L4继承了L3改进版本的IPC实现，速度惊人。IPC时间的这种数量级改进是通过各种优化技术实现的。

• 传递短消息的IPC消息中很大比例是非常短的。通过在寄存器中传输这些消息，可以获得两倍的性能改进。
  
• 复制大量数据信息，大多数微内核通过两个副本在进程之间传输消息，从进程A空间到内核空间再到进程B空间。性能影响非常大，特别是对于长消息，因为会发生Translation Lookaside Buffer（TLB）和缓存未命中。L4允许通过临时与发送方共享目标区域的方式进行单拷贝传输，从而使512字节的消息性能提高了两倍，对更长的消息性能提高更多。
  
• 延迟调度，传统的IPC需要更新线程调度程序队列。可以通过延迟队列内/队列之间的线程移动来提高性能，直到队列被查询。这种”延迟”调度是通过在线程控制块中设置状态标志来实现的，然后在查询时扫描应该移动到不同队列的线程的队列。这削弱了队列的语义，偶尔会导致代价高昂的队列操作，但是总体上提高了小消息IPC的性能大约25%。
  

1. HelenOS

2. Genode

1. Monolithic kernels(宏内核)

   1. 概述
      

Unix 家谱：

1. FreeBSD

2. OpenBSD

3. SunOS

4. Solaris

5. Linux

   1. Android

   2. Chrome OS

1. Firefox OS

1. KaiOS

2. webOS

3. TrueOS

1. Hybrid

   1. 概述
      

A hybrid kernel is, as its name indicates, a hybrid between a Monolithic kernel and a Microkernel. Unlike a microkernel where everything takes place in user level servers and drivers, the designers of a hybrid kernel may decide to keep several components inside kernel and some outside. There are many motivations for doing so, such as performance, simplicity, and vendor lock-in (you cannot change components with custom components). Most hybrid kernels start as monolithic kernels and begin moving components into user land, primarily as security to support 3rd-party components and drivers which may be malicious or buggy.

An example of a hybrid kernel design may keep the VFS and bus controllers inside the kernel, but have the file system drivers and storage drivers as user mode programs. The advantage of this system that is you keep the performance and design principles of a monolithic kernel, but you allow untrusted users to load untrusted code for accessing their own storage devices.

1. Windows NT

Windows 重构的核心是名叫 API sets 的机制，将 DLL 与实现环境分离开来；Windows NT 从某种意义上说就像是一个微内核，它有一个核心内核 (KE)，但几乎不做什么，它使用执行层 Ex 执行所有高级策略。

Ex 仍然是内核模式，所以它不是真正的微内核；Windows 内核子系统包括了内存管理、注册表、电源、执行 Ex、安全、内核和进程子系统，其中内存管理的代码行数最多，有超过 50 万行；

Windows 的调度器主要是根据优先级别去决定运行某个线程，Windows 7 引入了动态公平分享调度器，Windows 10 引入了 CPU Sets。

NT内核具有以下几个特征（摘自Undocumented Windows NT）：

Portability （可移植性）

如你所知，Windows NT 可以运行在多种平台上，即 Intel、MIPS、Power PC 和 DEC Alpha。众多厂商都为 Windows NT 的可移植性做出了贡献。 其中最为重要的因素可能是其实现所使用的语言。Windows NT 大部分是用 C 语言编写的，也有一部分用的是 C++。 平台相关的汇编语言只在必需的地方才用到。Windows NT 团队还将操作系统中硬件相关的部分与其它部分隔离开，单独放进了 HAL.DLL。 如此一来，Windows NT 中与硬件无关的部分的代码就可以用 C 之类的高级语言来编写，也因此可以很容易地移植到各种平台。

Extensibility（可扩展性）

Windows NT 具有很高的可扩展性，但因为缺少文档，其可扩展的特性却极少得到发掘。未公开的特性的名单中，子系统首当其冲。子系统在操作系统中提供了多种操作系统接口。只需添加新的子系统程序就可以为 Windows NT 扩展新的操作系统接口，但是对于公开添加新子系统过程的要求微软却一直打马虎眼。

Windows NT 的内核是高可扩展的，因为可以将内核模块作为驱动程序动态加载。对于 Windows NT，微软提供了足够的文档来编写硬件设备驱动——即硬盘驱动、网卡驱动、磁带机驱动等等。在 Windows NT 下还可以编写不控制设备的驱动程序。甚至连文件系统也是作为驱动程序加载的。

Windows NT 的可扩展性的另一个例子就是系统调用接口的实现。 开发者要修改操作系统行为，一般都需要钩挂或添加系统调用。 Windows NT 的开发团队实际了良好的系统调用接口以方便钩挂和添加系统调用。但是微软还是没有公开这些机制。

Compatibility（兼容性）

长久以来，向下兼容性都是 Intel 处理器和微软操作系统的一大特征，也是这两位巨人成功的关键。Windows NT 必须能运行 DOS、Win16 和 OS/2 的程序。兼容性是 Windows NT 开发团队使用子系统概念的另一个原因。除二进制兼容之外（执行不同格式的可执行文件），Windows NT 还为符合 POSIX 的程序提供了源代码级的兼容。增强兼容性的其他方面还表现在除自己本身的 NTFS 外，Windows NT 支持其它的文件系统，如 DOS 的 FAT 和 OS/2 的 HPFS。

Maintainability（可维护性）

Windows NT 的代码量很大，维护着些代码的工作量也相当大。NT 的开发团队通过使用面向对象的设计实现了高可维护性。再有，将操作系统的功能分成各个层也提高了可维护性。最上面的一层，也就是用户见到的操作系统层面，是子系统层。子系统提供系统调用接口来为外界提供应用程序编程接口。在系统调用接口层之下的是 NT 的 executive，executive 又建立在内核之上，而内核又依赖于硬件抽象层（HAL），硬件抽象层与硬件直接通讯。

NT 的开发团队所选的编程语言也与 Windows NT 的可维护性有关。正如我们前面提到的，整个操作系统都是用 C 和 C++ 来编写的，只有极少数不用不行的地方用了汇编语言。

Security（安全性）

Windows NT 是一个安全的操作系统，是因为它有以下几点特征：用户在使用系统之前必须先登陆。 系统中的资源都被视为对象，而每一个对象都相应由一个安全描述符。安全描述符有一个安全列表来指示那些用户可以访问该对象。

尽管有这些，要是没有一个安全的文件系统，操作系统也不能说是安全的。 DOS 时的 FAT 文件系统没有预见到任何的安全问题，其作为一个单用户的系统，也不用防范安全问题。

为了克服此缺陷，Windows NT 团队推出了一种新的文件系统，这种文件系统基于 OS/2 的文件系统 HPFS。这种新的 Windows NT 的自有文件系统叫 NTFS。它支持访问控制，用户可以为 NTFS 下创建的文件或目录指定访问权限，NTFS 只允许有访问权限的进程访问该文件或目录。

Multiprocessing（多进程）

Windows NT 支持对称多处理，Windows NT 的工作站版本可以支持两个处理器，服务器版可以支持到4个。为支持多处理，操作系统需要特殊的同步机制。在单处理器系统中，通过禁用中断，临界区中的代码执行时不会被打断。这对于维护内核数据结构的完整性来说是必需的。在多处理器环境下，就不可能在所有的处理器上都禁用中断。在多处理环境中，Windows NT 使用自旋锁来保护内核数据结构。

注：多处理可分为对称的和非对称的。在非对称多处理中，有一个处理器为主处理器，其它的处理器都为从处理器。只有主处理器运行在内核模式，其它从处理器都只运行在用户线程。只要运行在用户线程的从处理器一调用系统服务，主处理器就接管此线程并执行所需的内核服务。调度程序，一个内核程序，之运行在主处理器上。因此，主处理扮演者调度员的角色，将用户模式线程分派给从处理器。很自然，与所有处理器都可在内核或用户模式运行的对称多处理相比，主处理器负担很重，系统不均衡。

International Language Support（国际化语言支持）

如今众多的 PC 用户都使用英语之外的其它语言。与这些用户能很好交互的关键就是使操作系统能支持用户们的语言。Windows NT 通过使用 Unicode 标准的字符集实现了这一目标。Unicode 标准规定了一个16位的字符集，而ASCII 使用的是8位字符集。 Unicode 的前256个字符的编码与 ASCII 的相同。这就为非拉丁语的语言留出了充足的空间。Win32 API 能接受 Unicode 和 ASCII 两种字符集，而 Windows NT 的内核则只能使用 Unicode。尽管应用程序程序员可以不去了解 Unicode，但驱动程序的开发者必须熟悉 Unicode，因为内核接口函数只接受 Unicode 字符串而且驱动的入口点都用的是 Unicode。

Windows NT 中有两种子系统： integral subsystems 和 environment subsystems。Integral subsystems，如安全管理子系统，完成基本的操作系统任务。 Environment subsystems 则使得一台 Windows NT 机器能使用不同种类的 APIs。Windows NT 的子系统能支持以下的 APIs：

Win32 子系统。Win32 子系统提供 Win32 API。使用 Win32 API 的应用程序可以运行在微软 提供的所有平台上—

WOW 子系统。Windows on Windows (WOW) 子系统提供了对 16-bit Windows 应用程序的兼容，使得 Win16 的应用程序可以在 Windows NT 上运行。只要没有使用 Windows NT 不支持的未公开函数，这些应用程序都可以运行。

NTVDM 子系统。NT Virtual DOS Machine (NTVDM) 提供了一个基于文本的环境，DOS 程序可以在这个环境中运行。

OS/2 子系统。OS/2 子系统能运行 OS/2 应用程序。WOW、NTVDM 和 OS/2 都只能用在 Intel 平台上，因为他们都对应用程序提供二进制兼容性。而用于一种处理器的可执行文件或二进制文件就不能用在另一种处理器上，因为处理器间的机器指令格式不同。

POSIX 子系统。POSIX 子系统提供符合 POSIX 1003.1 标准的 API。

1. Windows 10 IoT

Windows 10 IoT Core: Built for small, secured smart devices, Windows 10 IoT Core embraces a rich UWP app experiences and provides support for ARM CPUs.

1. Mach (Mac OS)

macOS 内核被官方称为 XNU。这个首字母缩写词代表”XNU is Not Unix”。根据苹果公司的 Github 页面，XNU 是”将卡耐基梅隆大学开发的 Mach 内核和 FreeBSD 组件整合而成的混合内核，加上用于编写驱动程序的 C++ API”。代码的 BSD 子系统部分”在微内核系统中通常实现为用户空间的服务”。Mach 部分负责底层工作，例如多任务、内存保护、虚拟内存管理、内核调试支持和控制台 I/O。

1. Haiku

2. ReactOS

3. Plan 9

1. Unikernel (LibOS, Exokernel)

https://en.wikipedia.org/wiki/Unikernel

A unikernel is a specialised, single address space machine image constructed by using library operating systems.

1. Exokernels

An exokernel is a type of operating system where the kernel is limited to extending resources to sub operating systems called LibOS’s. Resulting in a very small, fast kernel environment. The theory behind this method is that by providing as few abstractions as possible programs are able to do exactly what they want in a controlled environment. Such as MS-DOS achieved through real mode, except with paging and other modern programming techniques.

1. AROS

2. MirageOS

https://mirage.io/

MirageOS is a library operating system that constructs unikernels for secure, high-performance network applications across a variety of cloud computing and mobile platforms. Code can be developed on a normal OS such as Linux or MacOS X, and then compiled into a fully-standalone, specialised unikernel that runs under a Xen or KVM hypervisor.

1. OSv

http://osv.io/

https://github.com/cloudius-systems/osv

OSv is the versatile modular unikernel designed to run unmodified Linux applications securely on micro-VMs in the cloud. Built from the ground up for effortless deployment and management of micro-services and serverless apps, with superior performance.

1. ClickOS

ClickOS is a high-performance, virtualized software middle box platform based on open source virtualization. Early performance analysis shows that ClickOS VMs are small (5MB), boot quickly (as little as 20 milliseconds), add little delay (45 microseconds) and more than 100 can be concurrently run while saturating a 10Gb pipe on an inexpensive commodity server.

1. Runtime.js

Runtime.js is an open-source library operating system for the cloud that runs on JavaScript VM, could be bundled up with an application and deployed as a lightweight and immutable VM image. Runtime.js is built on the V8 Javascript engine and currently supports QEMU/KVM hypervisor.

1. Adeos

Adeos (Adaptive Domain Environment for Operating Systems) is a nanokernel hardware abstraction layer (HAL) or a hypervisor that operates between computer hardware and the operating system that runs on it.[1] It is distinct from other nanokernels, in that it is not just a low level layer for an outer kernel. Instead it is intended to run several kernels together, which makes it similar to virtualization technologies.

Adeos provides a flexible environment for sharing hardware resources among multiple operating systems, or among multiple instances of a single OS, thereby enabling multiple prioritized domains to exist simultaneously on the same hardware.

Adeos has been successfully inserted beneath the Linux kernel, opening a range of possibilities, such as SMP clustering, more efficient virtualization, patchless kernel debugging and real-time systems for Linux.

Unusually among HALs, Adeos can be loaded as a Linux loadable kernel module to allow another OS to run along with it. In fact Adeos was developed in the context of RTAI (Real-Time Application Interface) to modularize it and to separate the HAL from the real-time kernel.

1. RTOS

https://en.wikibooks.org/wiki/Embedded_Systems/Common_RTOS

https://en.wikipedia.org/wiki/Comparison_of_real-time_operating_systems

1. 国内

   1. RT-Thread

https://www.rt-thread.org/

RT-Thread，全称是 Real Time-Thread，它是一个嵌入式实时多线程操作系统，基本属性之一是支持多任务，允许多个任务同时运行，但并不是真正的同时运行，而是宏观上的并行。

在 RT-Thread 系统中，任务通过线程实现的，RT-Thread 中的线程调度器就是任务调度器。

RT-Thread 主要采用 C 语言编写，浅显易懂，UNIX代码风格，POSIX接口支持方便移植。而对于资源丰富的物联网设备，RT-Thread，又能使用在线的软件包管理工具，配合系统配置工具实现直观快速的模块化裁剪，无缝地导入丰富的软件功能包，实现类似 Android 的图形界面及触摸滑动效果、智能语音交互效果等复杂功能。

相较于 Linux 操作系统，RT-Thread 体积小，成本低，功耗低、启动快速，除此以外 RT-Thread 还具有实时性高、占用资源小等特点。

RT-Thread 系统完全开源，遵循 Apache License 2.0 开源许可协议，可以免费在商业产品中使用，并且不需要公开私有代码。

RT-Thread 与其他很多 RTOS 如 FreeRTOS、uC/OS 的主要区别之一是：它不仅仅是一个实时内核，还具备丰富的中间层组件，如下图所示。

内核层：RT-Thread 内核，是 RT-Thread 的核心部分，包括了内核系统中对象的实现，例如多线程及其调度、信号量、邮箱、消息队列、内存管理、定时器等；libcpu/BSP（芯片移植相关文件 / 板级支持包）与硬件密切相关，由外设驱动和 CPU 移植构成。

组件与服务层：组件是基于 RT-Thread 内核之上的上层软件，例如虚拟文件系统、FinSH 命令行界面、网络框架、设备框架等。采用模块化设计，做到组件内部高内聚，组件之间低耦合。

RT-Thread 软件包：运行于 RT-Thread 物联网操作系统平台上，面向不同应用领域的通用软件组件，由描述信息、源代码或库文件组成。

1. LiteOS

https://www.huawei.com/minisite/liteos/en/

Huawei LiteOS是华为针对物联网领域推出的轻量级物联网操作系统，是华为物联网战略的重要组成部分，具备轻量级、低功耗、互联互通、组件丰富、快速开发等关键能力，基于物联网领域业务特征打造领域性技术栈，为开发者提供 “一站式” 完整软件平台，有效降低开发门槛、缩短开发周期，可广泛应用于可穿戴设备、智能家居、车联网、LPWA等领域。

Huawei LiteOS自开源社区发布以来，围绕物联网市场从技术、生态、解决方案、商用支持等多维度使能合作伙伴，构建开源的物联网生态,目前已经聚合了50+ MCU和解决方案合作伙伴，共同推出一批开源开发套件和行业解决方案，帮助众多行业客户快速的推出物联网终端和服务，客户涵盖抄表、停车、路灯、环保、共享单车、物流等众多行业，加速物联网产业发展和行业数字化转型。

关键特性:

• 低功耗框架：LiteOS是轻量级的物联网操作系统，最小内核尺寸仅为6KB，具备快速启动、低功耗等优势，Tickless机制显著降低传感器数据采集功耗。
  
• OpenCPU架构：专为LiteOS小内核架构设计，满足硬件资源受限需求，比如LPWA场景下的水表、气表、车检器等，通过MCU和通信模组二合一的OpenCPU架构，显著降低终端体积和终端成本。
  
• 安全性设计：构建低功耗安全传输机制，支持双向认证、FOTA固件差分升级，DTLS/DTLS+等，构建低功耗安全传输机制。
  
• 端云互通组件：LiteOS SDK端云互通组件是终端对接到IoT云平台的重要组件，集成了 LwM2M、CoAP、MQTT、mbed TLS、LwIP等全套IoT互联互通协议栈，大大减少开发周期，快速入云。
  
• SOTA远程升级：SOTA远程升级，通过差分方式降低升级包的尺寸，更能适应低带宽网络环境和电池供电环境，经过特别优化差分合并算法，对RAM资源要求更少，满足海量低资源终端的升级诉求。
  
• LiteOS Studio：LiteOS Studio是LiteOS集成开发环境，一站式开发工具，支持C、C++、汇编等语言，让您快速，高效的进行物联网开发。
  

1. 国外

   1. VxWorks

VxWorks is a real-time operating system (RTOS) developed as proprietary software by Wind River Systems, a wholly owned subsidiary of TPG Capital, US. First released in 1987, VxWorks is designed for use in embedded systems requiring real-time, deterministic performance and, in many cases, safety and security certification, for industries, such as aerospace and defense, medical devices, industrial equipment, robotics, energy, transportation, network infrastructure, automotive, and consumer electronics.

1. ThreadX

https://rtos.com/solutions/threadx/real-time-operating-system/

ThreadX, developed and marketed by Express Logic of San Diego, California, United States, is a highly deterministic, embedded real-time operating system (RTOS) written mostly in C. Express Logic was purchased for an undisclosed sum by Microsoft on April 18, 2019.

The name ThreadX is derived from the fact that threads are used as the executable elements and the letter “X” represents context switching, i.e., it switches threads. ThreadX provides priority-based, preemptive scheduling, fast interrupt response, memory management, interthread communication, mutual exclusion, event notification, and thread synchronization features. Major distinguishing technology characteristics of ThreadX include preemption-threshold, priority inheritance, efficient timer management, picokernel design, event-chaining, fast software timers, and compact size. The minimal footprint of ThreadX on an ARM processor is on the order of 2KB.

1. µC/OS-III (MicroC/OS)

https://www.micrium.com/rtos/kernels/

Micro-Controller Operating Systems (MicroC/OS, stylized as μC/OS) is a real-time operating system (RTOS) designed Jean J. Labrosse in 1991. It is a priority-based preemptive real-time kernel for microprocessors, written mostly in the programming language C. It is intended for use in embedded systems.

MicroC/OS allows defining several functions in C, each of which can execute as an independent thread or task. Each task runs at a different priority, and runs as if it owns the central processing unit (CPU). Lower priority tasks can be preempted by higher priority tasks at any time. Higher priority tasks use operating system (OS) services (such as a delay or event) to allow lower priority tasks to execute. OS services are provided for managing tasks and memory, communicating between tasks, and timing.

μC/OS-III is the acronym for Micro-Controller Operating Systems Version 3, introduced in 2009 and adding functionality to the μC/OS-II RTOS.

μC/OS-III offers all of the features and functions of μC/OS-II. The biggest difference is the number of supported tasks. μC/OS-II allows only 1 task at each of 255 priority levels, for a maximum of 255 tasks. μC/OS-III allows any number of application tasks, priority levels, and tasks per level, limited only by processor access to memory.

μC/OS-II and μC/OS-III are currently maintained by Micrium, Inc., a subsidiary of Silicon Labs, and can be licensed per product or per product line.

1. Zephyr

https://www.zephyrproject.org/

The Zephyr OS is based on a small-footprint kernel designed for use on resource-constrained and embedded systems: from simple embedded environmental sensors and LED wearables to sophisticated embedded controllers, smart watches, and IoT wireless applications.

The Zephyr kernel supports multiple architectures, including ARM Cortex-M, Intel x86, ARC, NIOS II, Tensilica Xtensa and RISC-V 32.

Zephyr项目是一个Linux基金会托管的协作项目，一个开源合作项目，联合了业内领先企业，为所有资源受限设备构建了针对资源受限设备进行优化的最佳小型可扩展实时操作系统（RTOS）。Zephyr支持ARM、x86（含x86_64体系）、ARC、NIOS II、Xtensa、Native POSIX、RISC V、Shields Bluetooth。支持的功能有Bluetooth Low Energy, Wi-Fi, 802.15.4，6Lowpan, CoAP, IPv4, IPv6, 和 NFC 等标准，通过社区驱动的发展来改进和增强功能。

Zephyr 源自2015年Wind River为IoT设备开发的Rocket内核， 2016成为Linux Foundation的一个项目。Zephyr 项目的初创成员有：英特尔公司(包括收购的Altera Corporation 和 Wind River)、恩智浦半导体公司(包括最近并购的 Freescale)和Synopsys公司。2016年，Linaro加入Zephyr项目，与Intel，NXPSemiconductors和Synopsys初创成员都为白金会员。2017年2月，Runtime.io和Nordic半导体公司加入Zephyr项目，成为其白银会员。oticon也为白银会员。

系统特色：

• 单个地址空间。将特定于应用程序的代码与定制的内核组合在一起，以创建一个在系统硬件上加载并执行的单片图像。应用程序代码和内核代码都在单个共享地址空间中执行。 [5]
  
• 高度可配置。允许应用程序只包含所需的功能，并指定它们的数量和大小。
  
• 编译时资源定义。允许在编译时定义系统资源，从而减少代码大小并提高性能。
  
• 最小的错误检查。提供最少的运行时错误检查，以减少代码大小并提高性能。提供了一个可选的错误检查基础结构来帮助在应用程序开发过程中进行调试。
  
• 广泛的服务套件：Zephyr™操作系统为软件开发提供了许多熟悉的服务，其中包含：
  
• 多线程服务 – 可以用于以优先级为基础非抢占式的纤程，以及以优先级为基础抢占式，可选轮询时间分片的任务。
  

1. FreeRTOS

https://www.freertos.org/

FreeRTOS is a real-time operating system kernel for embedded devices that has been ported to 35 microcontroller platforms. It is distributed under the MIT License.

FreeRTOS is designed to be small and simple. The kernel itself consists of only three C files. To make the code readable, easy to port, and maintainable, it is written mostly in C, but there are a few assembly functions included where needed (mostly in architecture-specific scheduler routines).

1. Nuttx

https://nuttx.org/

NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. Scalable from 8-bit to 32-bit microcontroller environments, the primary governing standards in NuttX are Posix and ANSI standards. Additional standard APIs from Unix and other common RTOS’s (such as VxWorks) are adopted for functionality not available under these standards, or for functionality that is not appropriate for deeply-embedded environments (such as fork()).

1. eCos

http://ecos.sourceware.org/

eCos is a free open source real-time operating system intended for embedded applications. The highly configurable nature of eCos allows the operating system to be customised to precise application requirements, delivering the best possible run-time performance and an optimised hardware resource footprint. A thriving net community has grown up around the operating system ensuring on-going technical innovation and wide platform support.

1. RIOT

http://www.riot-os.org/

RIOT is a small operating system for networked, memory-constrained systems with a focus on low-power wireless Internet of Things (IoT) devices. It is open-source software, released under the GNU Lesser General Public License (LGPL).

1. TinyOS

http://www.tinyos.net/

TinyOS is an open source, BSD-licensed operating system designed for low-power wireless devices, such as those used in sensor networks, ubiquitous computing, personal area networks, smart buildings, and smart meters. It is written in the programming language nesC, as a set of cooperating tasks and processes. It began as a collaboration between the University of California, Berkeley, Intel Research, and Crossbow Technology, was released as free and open-source software under a BSD license, and has since grown into an international consortium, the TinyOS Alliance.

TinyOS is fully non-blocking: it has one call stack. Thus, all input/output (I/O) operations that last longer than a few hundred microseconds are asynchronous and have a callback. To enable the native compiler to better optimize across call boundaries, TinyOS uses nesC’s features to link these callbacks, called events, statically. While being non-blocking enables TinyOS to maintain high concurrency with one stack, it forces programmers to write complex logic by stitching together many small event handlers. To support larger computations, TinyOS provides tasks, which are similar to a Deferred Procedure Call and interrupt handler bottom halves. A TinyOS component can post a task, which the OS will schedule to run later. Tasks are non-preemptive and run in first in, first out order. This simple concurrency model is typically sufficient for I/O centric applications, but its difficulty with CPU-heavy applications has led to developing a thread library for the OS, named TOSThreads. TOSThreads are unmaintained and have been deprecated.

1. RTLinux

RTLinux is a hard realtime real-time operating system (RTOS) microkernel that runs the entire Linux operating system as a fully preemptive process. The hard real-time property makes it possible to control robots, data acquisition systems, manufacturing plants, and other time-sensitive instruments and machines from RTLinux applications. Even with a similar name it is not related the Real-Time Linux project of the Linux Foundation.

RTLinux was developed by Victor Yodaiken, Michael Barabanov, Cort Dougan and others at the New Mexico Institute of Mining and Technology and then as a commercial product at FSMLabs. Wind River Systems acquired FSMLabs embedded technology in February 2007 and made a version available as Wind River Real-Time Core for Wind River Linux. As of August 2011, Wind River has discontinued the Wind River Real-Time Core product line, effectively ending commercial support for the RTLinux product.

1. Xenomai

http://www.xenomai.org/

Xenomai is a real-time development framework cooperating with the Linux kernel, to provide a pervasive, interface-agnostic, hard real-time support to user space applications, seamlessly integrated into the Linux environment.

The Xenomai project was launched in August 2001. In 2003 it merged with the Real-Time Application Interface (RTAI) project to produce a production-grade real-time free software platform for Linux called RTAI/fusion, on top of Xenomai’s abstract real-time operating system (RTOS) core. Eventually, the RTAI/fusion effort became independent from RTAI in 2005 as the Xenomai project.

Xenomai is based on an abstract RTOS core, usable for building any kind of real-time interface, over a nucleus which exports a set of generic RTOS services. Any number of RTOS personalities called “skins” can then be built over the nucleus, providing their own specific interface to the applications, by using the services of a single generic core to implement it.

1. RTAI

https://www.rtai.org/

Real-time application interface (RTAI) is a real-time extension for the Linux kernel, which lets users write applications with strict timing constraints for Linux. Like Linux itself the RTAI software is a community effort. RTAI provides deterministic response to interrupts, POSIX-compliant and native RTAI real-time tasks. RTAI supports several architectures, including IA-32 (with and without FPU and TSC), x86-64, PowerPC, ARM (StrongARM and ARM7: clps711x-family, Cirrus Logic EP7xxx, CS89712, PXA25x), and MIPS.

1. LynxOS

https://www.lynx.com/products/lynxos-posix-real-time-operating-system-rtos

LynxOS® has been deployed in millions of embedded devices and has operated reliably for 30+ years across multiple safety- and security-critical embedded markets. It is a tried and true approach for hosting applications on a Unix-like OS model wherein all resources and application services are centrally managed by a common kernel and is best-suited for working with hardware architectures that predate virtualization.

Key Features:

• —Full POSIX® Conformance
  
• —Real-time Scheduling
  
• —Multi-core
  
• —Luminosity (Eclipse-Based IDE) Application and Kernel Debugging Support
  
• —GCC-Based Tool Chain
  
• —Access Control and Cryptographic Security
  
• —Intel® and PowerPC® CPU Support
  

1. OS-9

OS-9 is a family of real-time, process-based, multitasking, multi-user operating systems, developed in the 1980s, originally by Microware Systems Corporation for the Motorola 6809 microprocessor. It was purchased by Radisys Corp in 2001, and was purchased again in 2013 by its current owner Microware LP.

The OS-9 family was popular for general-purpose computing and remains in use in commercial embedded systems and amongst hobbyists. Today, OS-9 is a product name used by both a Motorola 68000-series machine language OS and a portable (PowerPC, x86, ARM, MIPS, SH4, etc.) version written in C, originally known as OS-9000.

1. PikeOS

https://www.sysgo.com/products/pikeos-hypervisor/

PikeOS is a commercial, hard real-time operating system (RTOS) that offers a separation kernel based hypervisor with multiple partition types for many other operating systems (called GuestOS) and applications. It enables users to build certifiable smart devices for the Internet of Things according to the high quality, safety and security standards of different industries.

PikeOS combines a real-time operating system (RTOS) with a virtualization platform and Eclipse-based integrated development environment (IDE) for embedded systems. It is a commercial clone of L4 microkernel family[1]. The PikeOS real-time operating system has been developed for safety and security-critical applications with certification needs in the fields of Aerospace & Defense, Automotive & Transportation, Industrial Automation & Medical, Network Infrastructures and Consumer Electronics.

One of the key features of PikeOS is the capability to safely execute applications with different safety and security levels concurrently on the same platform. This is achieved by the strict spatial and temporal segregation of these applications by means of software partitions. A software partition can be seen as a container with pre-allocated privileges that can have access to memory, CPU time, I/O, but also a predefined list of PikeOS services. With PikeOS, the term application refers to an executable linked against the PikeOS API library and running as a process inside a partition. Due to the nature of the PikeOS API, applications can range from simple control loops up to complete Para virtualized guest operating systems like Linux or hardware virtualized guests.

1. RTEMS

https://www.rtems.org/

The Real-Time Executive for Multiprocessor Systems or RTEMS is an open source Real Time Operating System (RTOS) that supports open standard application programming interfaces (API) such as POSIX. It is used in space flight, medical, networking and many more embedded devices using processor architectures including ARM, PowerPC, Intel, Blackfin, MIPS, Microblaze and more. Commercial support is available from US and European companies, and free support comes via the active global community. Major decisions about RTEMS are made by the core developers in concert with the user community, guided by the Mission Statement. We provide access to our development sources via a Git Repository (see these Instructions for details). We strive to provide regular, high-quality releases, which we want to work well on a wide range of embedded targets using cross development from a variety of hosts including GNU/Linux distributions, MS Windows, BSDs, Solaris, and Mac OS. We encourage everyone to contribute changes and feedback to RTEMS.

1. 高级语言操作系统

   1. gopher-os

https://github.com/achilleasa/gopher-os

A proof of concept OS kernel written in Go.

1. Redox OS

https://gitlab.redox-os.org/redox-os/redox

Redox is a Unix-like Operating System written in Rust, aiming to bring the innovations of Rust to a modern microkernel and full set of application.

1. Blog OS

https://github.com/phil-opp/blog_os

Writing an OS in Rust.

1. 未来

   1. 硬件架构

   2. 操作系统

现在操作系统的问题:

• 碎片化
  
• 安全问题
  

未来操作系统的趋势:

• 设备统一互联
  
• AI
  
• 虚拟现实
  
• 商业模式变化，免费
  

1. 新系统的挑战

现如今，操作系统不单单是技术开发问题，而是一个生态问题。新研发操作系统定然会面临冷启动问题，即如何从0开始累积用户。这是一个鸡与蛋式的困境，新的OS没有用户，所以没有开发者愿意去开发APP，没有APP就没有用户。因此，有这样的言论: 没有规矩不成方圆，没有生态称不上OS。