Plan 9 from Bell Labs 系统详解

Plan 9 from Bell Labs 是一个分布式操作系统，由贝尔实验室计算科学研究中心在 20 世纪 80 年代末期开始开发，旨在作为 Unix 的继任者。它的设计理念和技术实现与 Unix 及其后代（如 Linux）有显著不同，强调“一切皆文件”原则的彻底实现和网络透明性。尽管它在技术上具有创新性，但由于多种原因，它始终未能获得广泛应用，成为一个非常小众但备受推崇的操作系统。

起源与开发团队的愿景

Plan 9 的开发始于 1980 年代后期，由 Unix 的原始开发者 Ken Thompson 和 Dennis Ritchie，以及 Rob Pike, Dave Presotto, Phil Winterbottom 等人领导。他们在贝尔实验室的计算科学研究中心工作，这个地方也是 Unix 和 C 语言的诞生地。到了 80 年代，Unix 已经取得了巨大的成功，但在分布式计算、图形界面和多核处理器等新兴领域开始显露出一些设计上的局限性。

开发团队希望从头开始设计一个操作系统，而不是修补 Unix。他们的愿景是创建一个更简洁、更一致、更适合分布式环境的操作系统。他们认为 Unix 的许多方面已经变得复杂和不一致，特别是在处理网络和各种设备时。Plan 9 的目标是提供一个统一的、基于文件系统的接口来访问所有资源，从而简化系统设计和编程。他们希望 Plan 9 能够像 Unix 在单机时代那样，成为分布式计算时代的基石。

核心理念：一切皆文件 (Everything is a file) 的极致实践

Plan 9 继承了 Unix 的“一切皆文件”哲学，并将其推向了前所未有的极致。在 Plan 9 中，几乎所有的系统资源，包括文件、目录、设备、进程、网络连接、窗口、用户界面元素，甚至是一些抽象概念，都被表示为文件系统的层次结构中的文件或目录。用户和程序通过标准的文件系统操作（如 open, read, write, close, bind, mount 等）来访问和操作这些资源。

这种理念并非仅仅是将设备映射到 /dev 目录下的文件（如 Unix 那样），而是将 所有 资源都通过文件系统的接口暴露出来。例如：

• 设备： 鼠标、键盘、网卡、硬盘分区等硬件设备都对应文件系统中的文件。读写这些文件就是与设备进行交互。

• 进程： 系统中的每个进程都对应 /proc 目录下的一个子目录。这个子目录中包含描述进程状态的文件（如 status）和用于控制进程的文件（如 ctl）。通过读写 ctl 文件，可以向进程发送信号或改变其状态。

• 网络连接： 一个 TCP 连接可能被表示为文件系统中的一组文件，例如用于发送数据的 data 文件和用于控制连接的 ctl 文件。通过读写这些文件来发送和接收网络数据。

• 窗口： 在 Plan 9 的窗口系统 (rio) 中，每个窗口也是文件系统中的一个目录，包含 data 文件（窗口内容）、ctl 文件（窗口控制）等。

这种设计的核心优势在于：

1. 统一且简单的接口： 开发者只需要掌握一套标准的文件系统系统调用，就可以与系统中的各种资源进行交互，无需学习针对不同类型资源的复杂且不一致的 API。这极大地简化了系统编程。

2. 强大的组合性： 由于所有资源都是文件，可以利用文件系统的强大工具（如管道、重定向、脚本）来组合和操作这些资源。例如，可以将一个设备的输出通过管道连接到另一个设备的输入，或者将一个程序的输出重定向到一个网络连接。

3. 网络透明性： 这是“一切皆文件”理念在分布式环境中的重要体现。通过 Plan 9 的 9P 协议，可以将远程机器上的文件系统（包括设备、进程等资源）“挂载”到本地机器的文件系统树中。用户可以像访问本地文件一样访问远程资源，无需显式地使用特定的网络协议或远程访问命令。

关键技术特性详解

Plan 9 的独特技术特性是其区别于 Unix 和其他操作系统的地方：

1. 9P 协议 (Styx)：

   • 这是 Plan 9 的核心网络协议，用于在机器之间共享文件系统资源。它是一个轻量级的、面向消息的协议，设计用于高效地传输文件系统操作（如读、写、打开、关闭、创建、删除、获取属性等）。

   • 9P 协议允许一台机器充当文件服务器，将其文件系统树通过网络暴露出来。另一台机器可以作为客户端，使用 mount 命令将远程的文件系统树挂载到自己的本地命名空间中。

   • 不仅仅是传统的文件，任何通过文件系统接口暴露的资源（设备、进程、服务等）都可以通过 9P 协议进行访问。这使得构建分布式系统变得非常自然和灵活。

   • 9P 协议的设计简洁高效，易于实现，并且具有良好的可扩展性。

2. 命名空间 (Namespace)：

   • 这是 Plan 9 中一个非常重要的概念。每个进程都有自己的私有命名空间，它是一个文件系统树的视图。这个视图是进程对整个系统资源的感知。

   • 进程可以通过 bind 和 mount 系统调用动态地修改自己的命名空间。bind 允许将一个文件或目录绑定到命名空间中的另一个位置，类似于符号链接但更灵活。mount 允许将本地或远程的文件系统、设备、甚至其他进程暴露的资源挂载到命名空间中的某个目录。

   • 不同的进程可以拥有完全不同的命名空间，这提供了强大的隔离性和灵活性。例如，一个进程可以将一个特定的设备挂载到其命名空间中的一个方便的位置，而不会影响其他进程。

   • 命名空间的概念使得 Plan 9 非常适合构建分布式系统，因为进程可以根据需要将远程资源集成到自己的本地文件视图中。

3. 联合目录 (Union Directory)：

   • Plan 9 允许将多个目录的内容“联合”起来，形成一个逻辑上的单一目录。当访问这个联合目录时，系统会按照一个预定义的顺序在构成联合的各个目录中查找文件。

   • 例如，可以将一个包含系统默认命令的目录与一个包含用户自定义命令的目录联合起来，用户在访问这个联合目录时，就可以同时看到系统命令和自定义命令，并且系统会优先查找用户自定义的命令（如果设置了查找顺序）。

   • 联合目录在构建灵活的命名空间、管理不同版本的配置文件或程序时非常有用。

4. 分离的架构 (Distributed Architecture)：

   • Plan 9 被设计成一个天然的分布式系统，其核心思想是将不同类型的系统功能运行在专门的机器上。典型的 Plan 9 环境由以下类型的机器组成：

     • 终端 (Terminals)： 这些机器通常配置有显示器、键盘、鼠标，运行窗口系统和用户应用程序。它们通过网络连接到其他服务器，并将其命名空间挂载到文件服务器和 CPU 服务器。

     • 文件服务器 (File Servers)： 这些机器专门用于存储用户的文件和数据。它们通过 9P 协议将文件系统暴露给终端和 CPU 服务器。文件服务器通常具有大容量存储和良好的 I/O 性能。

     • CPU 服务器 (CPU Servers)： 这些机器提供计算能力，用于运行计算密集型任务。终端可以将程序发送到 CPU 服务器上执行，并通过 9P 协议访问文件服务器上的数据。CPU 服务器通常配置有强大的处理器。

   • 这种分离的架构使得系统资源可以集中管理和优化，并且用户可以根据需要访问不同机器上的资源，实现了资源的共享和负载均衡。

5. 窗口系统 (8½ / rio)：

   • Plan 9 的窗口系统最初是 8½，后来演变为 rio (Research Institute Oki)。与 X Window System 等主流窗口系统不同，rio 的设计非常简洁且与文件系统紧密集成。

   • 每个窗口、每个终端会话都被表示为文件系统中的一个目录。例如，一个窗口目录可能包含：

     • data 文件：用于向窗口写入文本或图形内容，以及从窗口读取用户输入。

     • ctl 文件：用于控制窗口的行为，如改变大小、位置、标题等。

     • event 文件：用于读取窗口事件，如鼠标点击、键盘输入等。

   • 用户和程序通过读写这些文件来与窗口进行交互。这种设计使得可以使用标准的文件系统工具和脚本来自动化窗口操作，并且窗口系统本身非常轻量级和高效。

6. 设备和进程作为文件：

   • 如前所述，硬件设备和运行中的进程都被抽象为文件系统中的文件或目录。

   • 例如，/dev/mouse 文件代表鼠标设备，读取它可以获取鼠标的当前位置和按键状态。向 /dev/mouse 写入特定的命令可以改变鼠标的行为（如果设备支持）。

   • /proc 目录下的每个子目录代表一个进程，其中包含 ctl 文件用于控制进程（如杀死进程），status 文件用于查看进程状态，mem 文件用于访问进程的内存空间（如果权限允许）。

   • 这种一致的“一切皆文件”接口极大地简化了系统管理和编程。

7. 没有超级用户 (root)：

   • Plan 9 没有像 Unix 那样的全局超级用户（root）概念。在 Unix 中，root 用户拥有对系统资源的完全控制权，这既强大但也带来了潜在的安全风险。

   • 在 Plan 9 中，权限控制是基于每个资源的访问控制列表 (ACL) 或基于用户身份。用户对其自己拥有的资源（文件、进程等）拥有完全控制权。对于其他用户的资源或系统资源，访问权限由资源的 ACL 或系统策略决定。

   • 这种设计提供了一种更细粒度的权限管理方式，避免了单一超级用户的风险。

8. UTF-8 原生支持：

   • Plan 9 是最早原生支持 UTF-8 字符编码的操作系统之一。在 20 世纪 90 年代初，当大多数操作系统还在使用各种不同的字符编码时，Plan 9 就已经将 UTF-8 作为其默认和首选的字符编码。这使得 Plan 9 在处理多语言文本方面具有先天的优势。

开发与演进

Plan 9 的开发经历了几个重要的阶段：

• 贝尔实验室内部开发 (1980s - 1990s)： 在这个阶段，Plan 9 是贝尔实验室的一个主要研究项目。团队在内部不断迭代和完善系统，发布了多个内部版本。这个时期确立了 Plan 9 的核心设计和技术。

• 公开发布版本 (1992 - 2002)：

  • Plan 9 First Edition (1992): 首次公开发布，主要面向学术机构。

  • Plan 9 Second Edition (1995): 面向更广泛的受众，提供了安装媒介和文档。

  • Plan 9 Third Edition (2000): 增加了对更多硬件的支持和一些新特性。

  • Plan 9 Fourth Edition (2002): 最后一个由贝尔实验室正式发布的版本。

• 开源与社区维护 (2002至今)： 2002 年，贝尔实验室（当时属于朗讯科技）将 Plan 9 的大部分代码以 Lucent Public License 开源许可证发布。此后，Plan 9 的开发和维护主要由一个小型但活跃的社区负责。社区成员继续修复 bug，添加新的驱动程序和工具，并维护文档。

与 Unix 的主要区别

理解 Plan 9 的独特之处，最好的方式是将其与 Unix 进行对比：

• 文件系统理念： Unix 将文件、设备、进程等映射到文件系统，但 Plan 9 走得更远，将 所有 资源都通过文件系统接口暴露，包括网络连接、窗口等。

• 网络： Unix 通过套接字 API 处理网络，这与文件系统接口是分开的。Plan 9 通过 9P 协议将网络连接表示为文件，将其集成到文件系统中，实现网络透明性。

• 进程管理： Unix 使用 /proc 文件系统来暴露进程信息，但 Plan 9 将进程本身表示为 /proc 下的目录和文件，可以通过文件操作来控制进程。

• 权限： Unix 有一个强大的超级用户 (root)。Plan 9 没有全局超级用户，采用更细粒度的基于资源的 ACL 或用户身份的权限控制。

• 窗口系统： Unix 通常使用 X Window System，这是一个复杂的、基于网络的协议和架构。Plan 9 的 rio 窗口系统更轻量级，并与文件系统紧密集成，窗口本身就是文件。

• 命名空间： Unix 进程共享一个全局的文件系统视图（尽管可以通过 chroot 等进行有限隔离）。Plan 9 每个进程都有私有的、可动态修改的命名空间。

• 多核支持： Plan 9 在设计时考虑了多核处理器，其内核设计更适合并行执行。Unix 在多核支持方面经历了一个演进过程。

• 系统调用接口： Plan 9 的系统调用接口比 Unix 更小、更一致。

为什么它如此小众？

尽管技术上有很多创新之处，Plan 9 始终未能成为主流操作系统，原因复杂且相互关联：

1. 巨大的范式差异： Plan 9 的核心理念和使用方式与 Unix/Linux 或 Windows 等主流操作系统差异巨大。用户和开发者需要学习一套全新的思维方式和命令集。这种学习曲线对于习惯了传统操作系统的用户来说是一个巨大的障碍。

2. 缺乏主流应用程序： 这是一个“鸡生蛋，蛋生鸡”的问题。几乎所有主流应用程序（如 Web 浏览器、办公套件、开发工具、游戏等）都是为 Unix-like 或 Windows 系统开发的，无法在 Plan 9 上直接运行。为 Plan 9 开发应用程序需要使用其特定的 API 和工具链，并且需要用 C 或 Plan 9 的特有语言（如 Limbo，尽管 Limbo 程序通常运行在一个虚拟机中，与核心系统汇编和 C 代码不同）编写。这导致 Plan 9 缺乏日常使用的实用性。

3. 硬件兼容性差： Plan 9 的设备驱动程序需要直接与硬件交互，并且通常需要用 C 语言（Plan 9 的主要系统编程语言）编写。由于社区规模小，为各种新硬件编写和维护驱动程序的资源非常有限。这导致 Plan 9 的硬件兼容性远不如主流操作系统，特别是对较新的硬件支持不足。用户需要特定的、通常是较旧的硬件才能顺利运行 Plan 9。

4. 社区规模小且分散： Plan 9 的开发者和用户社区非常小。这限制了其发展速度、bug 修复能力、文档完善程度和用户支持。虽然社区成员充满热情，但其规模不足以与 Linux 等大型开源社区竞争。

5. 缺乏商业支持和市场推广： 与 Unix 最初在学术界和商业界的推广不同，Plan 9 没有获得大型公司的商业支持或进行大规模的市场推广。这使得它主要停留在研究和爱好者领域。

6. Unix 的强大惯性： Unix 及其后代（特别是 Linux）已经建立了一个极其庞大且成熟的生态系统，拥有海量的软件、广泛的硬件支持、庞大的开发者群体、丰富的文档和成熟的商业支持。这种强大的惯性使得任何试图取代 Unix 的新系统都面临巨大的挑战。用户和企业已经投入了大量资源在 Unix-like 系统上，迁移成本极高。

7. 文档和学习资源相对有限： 尽管有一些优秀的 Plan 9 文档（如其手册页），但相比于主流操作系统，Plan 9 的学习资源相对有限，这进一步增加了学习难度。

现状与遗产

Plan 9 目前主要由一个爱好者社区维护和开发。它仍然是一个活跃的研究平台，吸引着对操作系统设计、分布式系统和“一切皆文件”理念感兴趣的技术人员。虽然不会在普通用户的电脑上看到 Plan 9，但它的设计思想对后续的一些系统和技术产生了影响：

• 命名空间的概念： 尽管实现方式不同，但命名空间的概念在一些现代系统中有所体现，例如 Linux 的 mount namespaces。

• 9P 协议： 9P 协议本身或其变种被用于一些特定的嵌入式系统或分布式应用中。例如，Linux 内核支持 9P 协议，允许 Linux 系统作为 9P 客户端或服务器。

• UTF-8 的推广： Plan 9 是早期采用并推广 UTF-8 的系统之一，对 UTF-8 成为互联网和现代操作系统的主要字符编码起到了推动作用。

• Go 语言： Go 语言的主要设计者（Ken Thompson, Rob Pike, Robert Griesemer）都曾是 Plan 9 的开发者。Go 语言的一些设计理念受到了 Plan 9 环境的影响，例如其并发模型和工具链设计。

• 学术研究： Plan 9 仍然是操作系统课程和研究中的一个重要案例，用于教授分布式系统、文件系统设计和操作系统原理。

总结

Plan 9 from Bell Labs 是一个具有里程碑意义的操作系统，它以其“一切皆文件”的彻底实现、基于 9P 协议的网络透明性和独特的分布式架构，为操作系统设计提供了新的视角。它是一个技术上的杰作，代表了对操作系统核心原则的深刻思考和大胆实践。然而，由于与主流操作系统的巨大差异、缺乏应用程序生态、硬件兼容性问题以及 Unix 的强大惯性，使其始终保持着小众的地位。它更多地被视为一个研究项目、一个技术探索的典范，而不是一个广泛使用的通用操作系统。它的存在提醒我们，在计算机科学领域，总有不同的路径和可能性值得探索，即使这些探索注定只属于少数人，它们也可能在未来以意想不到的方式影响技术的发展。Plan 9 是一个活生生的例子，说明了即使是来自最顶尖实验室、由最杰出的计算机科学家设计的系统，也可能因为与现有生态系统的巨大差异而难以普及，但其技术思想的价值却可能超越其自身的流行程度，在幕后产生深远的影响。