原文Mach: the core of Apple’s OS X CS-384, Operating System Design Winter 2005-2006
Table of Contents
- Introduction............................................................................................................ 3
- Overview of XNU ................................................................................................ 3
- Kernel Types........................................................................................................ 4
- Monolithic Kernels .............................................................................................. 4
- Microkernels...................................................................................................... 4
- The Mach Microkernel....................................................................................... 5
- Overview and History........................................................................................ 5
- Philosophy........................................................................................................... 6
- Abstractions.................................................................................................... 7
- Scheduling.................................................................................................... 8
- Interprocess Communication.......................................................................... 10
- Memory Management .................................................................................. 12
- Concerns Regarding Mach’s role in XNU....................................................... 13
- Conclusion ........................................................................................................... 14
- Works Cited.......................................................................................................... 15
引言
自2001年苹果发布基于UNIX的Mac OS X操作系统以来，在与Windows的竞争中获得了广泛的认可。尽管很多人还没有做出转变并开始使用Mac OS X，但是苹果对Intel微处理器架构的支持将推动人们使用Mac OS X的热情。Mac OS X架构的关键结构赋予其广为人知的良好的稳定性与优良的性能。这些核心组件的一份低水平分析表明，选用Mach作为系统内核的核心，对整个操作系统的效率起着决定性的作用。
XNU概述
苹果的 XNU (“X is not Unix”) 内核由三个核心组件组成，它们共同为Mac OS X提供基础功能[Apple 2006]。OS X内核最为出名的组件基于UNIX的伯克利标准发行（Berkley Standard Distribution，BSD）。包括在苹果内核中的BSD功能主要基于FreeBSD 5.x，提供诸如权限、POSIX函数的API、BSD风格的系统调用和文件系统关联等特性。虽然它不如Mac OS X的组件知名，但卡内基梅隆大学Mach 3.0微内核的一个衍生产品，提供了许多BSD衍生元素正常工作所必须的核心功能。它执行传统操作系统关键的职责如抢占式多任务、内存关联、进程间通信、内核调试和控制台输入与输出。I/O组件工具包是XNU内核的第三方组件，它提供基于嵌入式C++ 的面向对象的设备驱动控制[Singh 2006]。
内核类型
在操作系统的世界中有两种范畴的内核，巨内核与微内核。正如名字所暗示的，它们的主要差别就在于大小与所包括的功能范围[Galli 2000]。
- 巨内核 Monolithic Kernels
巨内核被一本教科书描述为“大混乱”，其结构可以总结为“没有结构”[Tanenbaum 2001]。一个巨内核即便不包含全部的也会包含大部分的操作系统能力，处理进程、内存、文件、名称与设备管理[Galli 2000]。它缺乏保护边界，不对功能进行封装 [Tanenbaum 2001] -任何函数可以引用任何其它函数或是数据。因为巨内核大量的代码并缺乏组织，所以很难进行debug、验证与修改。缺乏模块化使它们不适用于分布式计算，无法裁剪掉不用的系统模块 [Galli 2000]。
- Microkernels
微内核采用更加模块化的客户端/服务器的方式来进行操作系统设计。大量的功能从内核移除，只留下核心的功能。被移除的功能以用户级别例程实现，内核协调用户例程间的通信，如文件I/O例程，或是内存访问例程。 内核对访问服务的限制提供的封装特性可以最小化bugs的影响[Tanenbaum 2001]。如直接修改内核控制的变量引起的错误，如进程控制块，可能搞垮整个基于巨内核的系统，而协调的微内核限制访问这样敏感的信息并强迫所有的改变都是通过适当的方式与渠道完成。基于微内核操作系统架构的内在模块化特性，导致更易管理的部件，适合于分布式系统：客户端在一个系统上向运行于其它系统上的服务端发出数据请求。从客户端的角度来说，无论服务端在本地或是在远程，所发生的事情都是一样的：发出请求，返回应答 [Tanenbaum 2001]。在很多微内核中，特定计算机架构的功能被组织在单个模块中保存。因此，如有必要内核可以被移植到新的架构中而不用全部重写。已有的模块可以非常简单地被迁入，或是写新的模块满足新架构的需求[Galli 2000]。
Mach微内核
- 概述与历史
在80年代中期，卡内基梅隆大学计算机科学系开始开发Mach巨内核[Singh 2006]。起初的目的是作为 BSD 4.2的内核，Mach2.5版本实现大部分的BSD功能为单线程内核。因为不是多线程，所以并没有效率的限制。但随着代码库的扩张，BSD功能被从内核中抽取出来，放到外部库中，这便是微内核的风格了。而保留在内核中的代码库被称为Mach 3.0。因为与特定操作系统相关的BSD代码被拿出来放到用户级例程中，Mach微内核只是作为一个基础层，基于它可以构建不同的操作系统 [Silberschatz and Galvin 1993]。Mach的一个主要目标便是“作为一个能够运行于异质硬件上的分布式操作系统”。因此它以做好了支持任何地方的具有1到1000个处理器的系统，且稍作修改便可运行于广泛的计算机架构上。因于它根植于BSD，它于BSD 4.3的功能完全兼容，因此是苹果OS X内核良好的选择。BSD在苹果OS X中也起着基础性作用[Silberschatz and Galvin 1993]。
- Philosophy
除了支持不同厂商生产的多种单处理器多处理器计算机架构外，Mach开发者有意地限制了核心抽象的数量。 几乎所有的操作系统功能使用这样少数几个元素，避免了不必要的代码重复并把代码库控制在了一个合理的范围内。同时它也支持内置于内核中的内存管理与进程间通信能力，允许其它的关键操作系统功能，适用于广泛的架构与广泛的地域（使用计算机网络）。另外，UNIX研发背后大部分的哲学观点，如简易使用的API，庞大的库的应用库与实用库，管线的使用，影响了Mach架构的设计[Silberschatz and Galvin 1993]。尽管Mach内核根植与并受到BSD UNIX很大的影响，但是Mach的开发者试图避免UNIX本身的负面方面与错误。如UNIX对多核系统的支持是冗余且不可选择的。另外Mach试图采用UNIX中大量的抽象，并进一步泛化它们，创建一个最小的集同时提供内核的所有必要的功能 [Silberschatz and Galvin 1993]。
- 抽象
Mach内核开发的哲学理念确保了，在执行相似的任务时它与主要的UNIX版本同样高效。这样高的性能是通过下面六个基本的抽象来实现的[Silberschatz and Galvin 1993]：
-
Tasks – 通常在操作系统理论中被称作process，一个Mach task是基本的组织实体 [Kutrtzman and Dattatri 1995] ，具有自己独立的内存空间。 一个task自己无法执行，它包含一个或是多个共享task资源的线程 [Silberschatz and Galvin 1993] 。
-
Thread – Mach的thread概念与其它的当代多线程操作系统中的线程略有不同，它是系统中的执行实体。 线程有自己的寄存器、调度策略，只能在一个task上下文中存在 [Kutrtzman and Dattatri 1995] 。
-
Port – Mach使用ports作为内核控制的双向通道。为了通过通道发送或是接收数据，一个thread必须port访问权限[Silberschatz and Galvin 1993]。
-
Port Set – 正如其名字所暗示的，port set是port的集合，它们使用相同的消息队列。每个task只与一个port set关联。允许线程通过几个ports同时发送与接收消息，提升了效率 [Silberschatz and Galvin 1993]。
-
Message – Mach中的Messages是通信的最小单元，包含在线程间传的数据 [Silberschatz and Galvin 1993] 。
-
Memory Object – Memory objects包含byte可寻址数据，通过外部内存管理器管理[Kutrtzman and Dattatri 1995]。Tasks创建到memory objects的引用，以便访问数据 [Silberschatz and Galvin 1993]。
-
调度
在保持其设计哲学的同时，Mach微内核给对称多处理器的调度方法做出了规定。线程具有优先级，通过运行就绪队列集合得到支持，包括几个本地的每个处理器独占的队列（处理器队列）和一个全局的系统范围内队列（全局队列）。这些运行队列下面是一个包含了32个双向链表优先队列 [Black 1990]的数据结构。全局（就绪）队列有一个有趣的现象：内核会给全局就绪队列上锁，以阻止多处理器的同时修改 [Silberschatz and Galvin 1993]。
在Mach的早期版本中，就绪队列管理具有0-127的优先级别线程。之后的修改使线程优先级和就绪队列数更紧密额关联起来（32个双向列表）。因此，priorities现在是从0-31 [Black 1990]，线程的优先级数根据两个因素来决定：基值与反应CPU使用历史的偏移[Galli 2000]（需要内容补充）。为了阻止线程饥饿，Mach每两秒钟便会增大一次已有线程的优先级数[Black 1990]。
为了更有效的消除调度低效，Mach允许线程向内核提供两种类型的提示，来给低优先级的进程一个大的优先级以便有机会被调度使用CPU。这个设计是非常有用的，如一个低优先级的进程必须先执行某个功能，然后高优先级的进程才可以继续执行。阻止提示有三种强度-温和、强烈和绝对，它会降低将给出提示的进程被切换到处理器上的可能性。绝对阻止提示，在一定时间内阻止发出提示的线程被放到CPU上执行。强阻止提示，降低一个线程自己的优先级，但温和提示只是简单的提示CPU应该避免调度该线程。切换提示，显式第告诉内核在发出提示的内存位置执行其它线程，主动放弃CPU[Galli 2000]。
每一个处理器都有自己的调度器。当决定哪个线程将会占用当前处理器时，调度器首先查询它自己的本地运行就绪队列。如果没有例程需要执行，它将会从全局的系统域的就绪队列选取并执行最高优先级例程。本地队列中的线程被绑定到处理器，线程保持在该处理器的就绪队列上（处理器队列是虚拟线程与物理线程（硬件即CPU与相关寄存器等资源）的同一点）。例如，连接到一号处理器上的硬件设备驱动器，将只会在一号处理器的运行就绪队列上调度，因为它是唯一的可以与硬件设备通信的处理器[Silberschatz and Galvin 1993]。
在调度器从本地运行就绪队列或全局运行就绪队列选择完最高优先级例程后，调度器给例程（线程）一个时间片。每10到100毫秒，产生一个中断，调度器降低执行例程的时间片值。当线程不再有存留的时间，内核上下文切换进来下一个已经就绪的例程或是将当前例程留在CPU上，这取决于谁的优先级高[Black 1990]。
- 进程间通信
在UNIX中，进程与系统的通信依赖于位置（注定了无法高效地做分布式部署）。发送者必须知道接收者的名字（地址），以便适当的对消息进行寻址。而Mach采用的是**位置独立的、面向对象的方法（port号）**来进行进程间通信[Silberschatz and Galvin 1993]。
所有的通信，无论是两个线程间，线程与内存间，两个不同的系统，或是一个线程与内核，都可被视为信息在两个对象间通过少数几个关键的Mach抽象传递。每个对象都是通过ports上的消息的格式接收指令 [Silberschatz and Galvin 1993]。为了在port上发送或是接收消息，一个线程的task必须拥有适当的权限。这些port权限包括，发送、一次发送、接收、port集与死亡名称。与结束的例程进入终止状态一样，被销毁的port的权限也会变成死亡名称（是一种权限）。一次发送权限，只允许消息的接收者，向发送者通过该port发送一次消息。死亡名称权限可以与传统操作系统理论中的终止例程（进程）进行比较[Kutrtzman and Dattatri 1995]。
通过内核控制的消息队列发送的消息，由两个主要部分组成 - 头与数据体。在头部中指明目标port与数据的长度，所有必要的响应都可以通过目标port发送给消息的请求者。Mach消息的数据部分包含多个数据对象。在Mach 2.5中，数据对象的总和不能超过8kb，但3.0没有这个限制。有多种形状与大小的数据对象，包括port权限、数字格式的原始数据、指向内存数据的指针。这些内存数据指针提供了在一个消息中传输task的整个地址空间的方法。当使用这些指针传输大量数据时，内核一定会开始起作用，以辅助数据的传输。如果发送者与接收者在一个系统上，内核遵循copy-on-write技术，只有在需要改写传递的数据时才发生为接收者复制数据的操作[Silberschatz and Galvin 1993]。
既然ports被实现为内核的一部分，对这一功能的任何使用都必须通过内核来进行，这进一步加强了port 权限。因为port的功能被安全的从用户级例程分离，tasks试图不适当的对通信进行干预的风险被最小化。**内核对整个通信过程的忽略（只是通信的通道）**使消息免于被模拟、错误定向或是伪造[Kutrtzman and Dattatri 1995]（为什么？）。
Mach对于通信的一劳永逸的方案，即使用一种技术，为所有的消息，提供传输服务，增强了对多进程和网络通信的支持。 它进一步证实了Mach的关键的哲学理念，即提供最小最快内核是可能的。进程间通信通常比较慢，但是Mach在操作系统核心实现进程间通信，加速了进程间通信。另外，因为只有一种通信方式存在，可以花费大量的精力来优化它，而不是开发几个低效的方法[Silberschatz and Galvin 1993]。
- 内存管理
内存对象，作为另一个Mach微内核的关键抽象，与系统中存在的其它对象的行为一样。它们也使用Mach强大的进程间通信，使用管线与消息传输数据。这种实现方式也提供允许开发者非常方便地尝试多种内存操作算法 [Silberschatz and Galvin 1993]。Mach的虚拟地址空间允许寻址超过4Gbytes的数据。这个地址空间并不是以单一的、连续的内存区分配给tasks，而是以块的方式。Paging是内存管理的工业标准方法，通常确保内存的优化使用。 正如对操作系统理论有基本理解的人所期待的一样， task中的所有线程共享相同的内存。共享内存的边界在父线程创建子线程时就指定好了。父线程可以给予子线程自己内存空间的拷贝，或是直接读写父线程空间的权限。尽管Mach不提供任何task内线程写内存冲突解决方案，但是每个task必须实现自己的保护机制，以阻止或是适当的减轻这样冲突的发生[Silberschatz and Galvin 1993]。
虽然内存管理不依赖于内核 - 提供用户进程来管理内存对象 - 但Mach仍为内存管理提供了大量的支持。因为Mach内核具有自己的内存需求，并且不是所有的基于用户的内存管理器满足Mach自身访问内存的需求，Mach提供一个默认的内存管理器。它使用一种Pageout技术，充分发挥了具有二次机会的FIFO的优势[Silberschatz and Galvin 1993] （a FIFO with second chance implementation）。
关于Mach在XNU中的角色的思考
苹果的狂热者与作家 Dan Knight 在其文章“OS X is Holding back the Mac”中宣称，Mach是OS X操作系统致命的弱点。他建议苹果苹果应该在OS X内核中抛弃Mach的使用，而应该选择基于Linux的巨内核。他引用了一篇 Wikipedia 文章，声称“微内核是低效的，因为所有的通信都发生在操作系统的不同部分间” [2005]。但是Knight的建议是建立在错误的假设上，即 OS X 没有对Mach任何修改而直接采用 Mach 实现了其微内核架构。
苹果在其移植UNIX/Linux应用到OS X系统的文档中提醒开发者，尽管“XNU是基于Mach微内核设计”，但是它也包括BSD功能，所以本质上“从技术角度来说不是一个微内核实现”。
苹果进一步解决Knight指出的疑虑，承认微内核与上层间的通信可导致性能的下降。据说这个问题已通过XNU内核中“Mach的优势与BSD的优势”的组合被解决[2006]。（把内核通信降到最低，良好的设计架构，正如router在组件化中的使用一样，需要衡量考虑很多东西，避免乱用）
无论整样说，Knight的提议都是很有趣味的。随着近期苹果想事实上的工业标准Intel架构的转向，“Knight关于OS X的其它方面可以从改变中受益是正确的”这一建议是十分合理的。我们面对的挑战是寻找在哪里、如何去做出这样的改善。然而Mach提供的坚实的基础并不会被某个突发奇想所取代，只有时间会验证所做出的改善是否真的是对已有XNU内核的优化，或是只有通过内核（XNU）的重写设计来获取优化。
结论
把Mach微内核的一个变种放置在Mac OS X的核心，是该操作系统成为现有的最强大的面向消费者的操作系统的一个最根本性的基础。通过单一通信方法的优化与少数几个核心抽象的使用，Mach对效率的重视使Mac OS X获得了成功。另外，使Mach在过去二十年中得到普及与广泛使用的架构独立性，使苹果能够转向Intel架构。尽管在OS X的XNU内核中使用Mach的决定具有挑战，但是其悠久的历史与长年的发展使我们无法从OS X的XNU内核将其移除。
Works Cited
- [Apple 2006] Porting UNIX/Linux Applications to Mac OS X, Apple Computer, Inc., developer.apple.com/documentati…. html (2006).
- [Black 1990] D. L. Black, “Scheduling Support for Concurrency and Parallelism in the Mach Operating System,” Computer, Volume 23, Number 5 (May 1990), pages 35-43.
- [Galli 2000] D. L. Galli, Distributed Operating Systems – Concepts & Practice, Prentice Hall, Inc. (2000).
- [Knight 2005] D. Knight, “OS X is Holding back the Mac,” Low End Mac, lowendmac.com/musings/05/1214.html (2005).
- [Kutrtzman and Dattatri 1995] S. Kurtzman and K. Dattatri, “Design Goals of Object-Oriented Wrappers for the Mach Microkernel,” Proceedings of the 40th IEEE Computer Society International Conference (1995), pages 367-371.
- [Silberschatz and Galvin 1993] A. Silberschatz, P. B. Galvin, “The Mach System,” Operating System Principles, Fourth Edition, Addison-Wesley, Inc. (1993), pages 897-921.
- [Singh 2006] A. Singh, “What is Mac OS X? – XNU: The Kernel,” kernelthread.com, www.kernelthread.com/mac/osx/arc… (2006).
- [Tanenbaum 2001] A. S. Tanenbaum, Modern Operating Systems, Second Edition, Prentice Hall, Inc. (2001).
扩展阅读
Mach 3 Kernel Principles
Mach 3 Kernel Interfaces
The Mach System
INSIDE MAC OS X - Kernel Environment
operating system concepts, ninth edition
