> For the complete documentation index, see [llms.txt](https://book.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.bsdcn.org/4.3-bsd-unix-cao-zuo-xi-tong-she-ji-yu-shi-xian/di-yi-bu-fen-gai-lan/1.3.-4bsd-de-she-ji-mu-biao.md).

# 1.3 4BSD 的设计目标

4BSD 是为研究共同体（近年又加上了商业共同体）开发、并部分地由其参与开发的研究系统。开发者在编写系统时考虑了许多设计问题。设计中有一些非传统的考量与输入，尽管如此，它们产出了具有商业重要性的成果。

早期系统由技术驱动。它们利用了当时其他 UNIX 系统中无从获得的硬件。这些新技术包括：

* 虚拟存储支持
* 第三方（非 DEC）外设的设备驱动
* 面向屏幕应用的终端无关支持库；用这些库开发了大量应用，包括屏幕编辑器 `vi`。

与 AT\&T 发行版在 32V 里的寥寥支持相比，4BSD 对数量庞大的流行第三方外设的支持，是其广受欢迎的一个重要因素。在其他厂商开始为基于 4.2BSD 的系统提供自己的支持之前，必须压低硬件成本的大学别无选择。

终端无关的屏幕支持如今看来也许平淡无奇，在当时却是伯克利软件走红的重要因素。

**4.2BSD 设计目标**

DARPA 希望伯克利把 4.2BSD 开发为 VAX 上的标准研究操作系统。为纳入 4.2BSD 设计了许多新设施，包括：全面修订的虚拟存储系统，以支持具有大型稀疏地址空间的进程；快得多的文件系统；进程间通信设施；以及联网支持。高速文件系统和修订后的虚拟存储系统，是从事计算机辅助设计与制造（CAD/CAM）、图像处理和人工智能（AI）的研究者所需要的。进程间通信设施为从事分布式系统研究的站点所需要。联网支持则主要出于 DARPA 的兴趣——把他们的研究者通过 56 Kbit/s 的 ARPA Internet 连接起来（尽管伯克利也有意在高速度局域网上取得好性能）。

我们没有尝试提供一个真正的分布式操作系统 \[Popek, 1981]，而是沿用了 ARPANET 资源共享的传统目标。之所以选择资源共享式的设计，原因有三：

* 这些系统分布广泛，要求管理自治。当时，真正的分布式操作系统需要一个中央管理机构。
* 已知的紧耦合系统算法不能很好地扩展。
* 伯克利的任务是吸纳当前已被证明的软件技术，而不是开发未经证明的新技术。

因此，系统提供了便于远程登录（`rlogin`、`telnet`）、文件传输（`rcp`、`ftp`）和远程命令执行（`rsh`）的手段，但所有主机都保留各自独立的身份，并不对用户隐藏。

由于时间所限，以 4.2BSD 之名发布的系统并未包含最初打算纳入的全部设施。特别是，修订后的虚拟存储系统没有进入 4.2BSD 发行版。不过，CSRG 继续努力跟进几个方面快速发展的硬件技术：网络系统支持范围广泛的硬件设备，包括 10 Mbit/s 以太网、环网和 NSC Hyperchannel 的多种接口；内核源码经过模块化与重排，便于移植到新的体系结构，包括微处理器和更大的机器。

**4.3BSD 设计目标**

4.2BSD 存在的问题是 4.3BSD 的动因之一。4.2BSD 包含许多新设施，其中一些存在错误，TCP 协议实现尤其如此。性能有所损失，部分原因在于符号链接的引入。有些设施因时间不足而未能纳入；另一些，如 TCP/IP 子网和路由支持，则是因为外界定稿太迟，来不及收进 4.2BSD。

商业系统通常在多个版本间保持向后兼容，以免现有应用报废。然而，维持兼容越来越难，因此多数研究系统很少或干脆不保持向后兼容。作为对其他研究者的折中，BSD 发行版通常向后兼容一个版本，但把已弃用的设施明确标出。这种做法既允许向新接口平稳过渡，又不束缚系统顺畅演化。具体到 4.3BSD，它与 4.2BSD 的向后兼容被认为对应用的可移植性极为重要。

4.3BSD 的 C 语言接口与 4.2BSD 的差别，仅在于终端接口的少数几条命令，以及一个进程间通信系统调用（`select`，见 2.6 节）中一个参数的用法。4.3BSD 还为建立信号处理程序的系统调用增加了一个标志，允许进程为信号请求 4.1BSD 语义而非 4.2BSD 语义（见 4.7 节）。这个标志的唯一目的，是让依赖旧语义的现有应用无需改写即可继续工作。

4.2BSD 与 4.3BSD 之间的实现变化用户往往看不见，但数量众多。例如，为改进对 TCP/IP 之外多种网络协议族（如 XEROX NS）的支持而做的修改。既然 4.3BSD 保留了早期伯克利系统的种种进步，本书对 4.3BSD 的考察也就是对伯克利系统主要特性的考察。

4.3BSD 的第二个发行版（下文称 4.3BSD Tahoe）在 VAX 之外增加了对 Computer Consoles 公司（CCI）Power 6（Tahoe）系列小型机的支持。它虽然与最初的 4.3BSD VAX 版大体相似，却包含许多修改和新特性。

**未来的 Berkeley 发行版**

4.3BSD 并不完美。尤其是虚拟存储系统，需要彻底更换。新的虚拟存储系统需要提供更适应当前大容量内存和慢速磁盘的算法，并减少对 VAX 体系结构的依赖。终端驱动一直被小心翼翼地保持兼容——不仅与第七版兼容，甚至与第六版兼容。这一特性曾有用处，如今用处渐小，尤其考虑到其命令和选项缺乏正交性。CSRG 计划发行一个 POSIX 兼容的终端驱动；既然 System V 将遵从 POSIX，这个终端驱动也将与 System V 兼容。总体而言，POSIX 兼容是一个目标。

目前计划中的其他 BSD 工作包括：实现国际标准化组织（ISO）协议套件中的网络协议、TCP/IP 的进一步性能改进与增强，以及其他网络协议的实现。

4.3BSD 最关键的缺陷是缺少分布式文件系统。与网络协议一样，没有哪个单一的分布式文件系统能在所有场合都提供足够的速度和功能。正如需要运行多种网络协议一样，常常也需要支持多种不同的分布式文件系统协议。因此，人们正在开发一个文件系统标准接口，它比 Sun Microsystems 为其网络文件系统（NFS）搭建的框架更一般化一些，但十分相似，以便同时支持多个本地和远程文件系统，就像 4.3BSD 支持多种网络协议那样 \[Sandberg, 1985]。

对 IPC 处理模块做灵活配置的原创工作，是贝尔实验室在 UNIX 第八版中完成的 \[Presotto & Ritchie, 1985]。这个流 I/O 系统基于 UNIX 字符 I/O 系统。它允许用户进程打开一个裸终端端口，然后插入适当的内核处理模块，例如做常规终端行编辑的模块。处理网络协议的模块也可以插入。把终端处理模块叠放在网络处理模块之上，就能在内核里高效而灵活地实现网络虚拟终端。不过，流模块有个问题：它们本质上是线性的，因而不能妥善处理基于数据报的网络中与多路复用相伴的扇入扇出；这类复用是在模块之下的设备驱动中完成的。第八版的流 I/O 系统被 System V Release 3 采纳，即 STREAMS 系统。

4.2BSD 网络设施的设计走了另一条路，以 `socket` 接口和灵活的多层网络体系结构为基础。这一设计允许单一系统支持具有流、数据报及其他访问方式的多套网络协议。协议模块既能处理把来自不同连接的数据复用到单一传输介质上，也能处理对从每个网络设备收到的数据按协议和连接做解复用。

人们计划用 V8 流 I/O 系统的思想重新设计内部协议分层。届时将采用套接字接口而非字符设备接口，解复用由内核中的网络协议在内部处理。不过，与流一样，复用层之上的内核协议模块之间的接口将遵循统一的约定。这一约定将允许把终端处理模块纳入网络流，产生高效的网络虚拟终端连接；还将允许内核支持基于标准传输协议的远程过程协议；最后，这个接口将提供一种机制，把内核协议框架延伸到用户进程中，以便为新协议做原型设计并执行网络监视功能。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://book.bsdcn.org/4.3-bsd-unix-cao-zuo-xi-tong-she-ji-yu-shi-xian/di-yi-bu-fen-gai-lan/1.3.-4bsd-de-she-ji-mu-biao.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.