> 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/2.1.-unix-she-shi-yu-nei-he.md).

# 2.1 UNIX 设施与内核

UNIX 内核提供四项基本设施：进程、文件系统、通信和系统启动。本节概述这四项基本服务分别在哪里描述。

1. 进程构成地址空间中的一条控制线程。创建、终止进程及以其他方式控制进程的机制在第 4 章描述。系统为每个进程多路复用各自独立的虚拟地址空间；这一存储管理在第 5 章讨论。
2. 文件系统与设备的用户接口相似；共同之处在第 6 章讨论。文件系统是一组有名字的文件、按树形层次组织的目录，外加操纵它们的一组操作，见第 7 章的阐述。文件驻留在磁盘等物理介质上，访问它们需要设备驱动，见第 8 章的论述。终端用来访问系统；终端的设备驱动是第 9 章的主题。
3. 传统 UNIX 系统提供的通信机制包括设备 I/O（第 8、9 章）、相关进程之间的单工可靠字节流（见 10.1 节的管道），以及异常事件的通知（见 4.7 节的信号）。4.3BSD 还有一套通用的进程间通信设施，在第 10 章描述。这套设施使用的访问机制不同于文件系统的访问机制，但连接一旦建立，就可以像访问管道一样访问它。此外还有一个通用的联网框架（第 11 章），通常作为进程间通信设施之下的一个层次使用。第 12 章详细描述一种具体的网络实现。
4. 任何真实的操作系统都有运行管理方面的问题，比如如何启动，见第 13 章。

2.4 节到 2.13 节给出与第 4 章到第 13 章对应的引论材料。我们将定义术语、提及基本的系统调用、考察历史发展，最后给出许多重大设计决策的理由。

**内核**

内核（kernel）是系统中提供基本系统设施的那一部分：它创建并管理进程，提供访问文件系统和通信设施的功能。这些功能称为系统调用（system call），在用户进程看来就像其他库子例程一样。系统调用是进程访问这些设施的唯一接口。系统调用机制的细节，以及一些并非由进程执行系统调用直接引发的内核机制，都在第 3 章描述。

用户通常通过一个命令语言解释器与系统交互，它称为 shell，或许还要加上其他用户应用程序。这类程序和 shell 都实现为一组组进程。这类程序的细节超出本书范围，本书几乎只集中于内核。

传统操作系统术语中的“内核”指一小块软件核心，只提供实现其他操作系统服务所必需的最少设施。在 Accent \[Fitzgerald & Rashid, 1986]、Tunis \[Ewens et al., 1985] 和 V 内核 \[Cheriton, 1988] 这类当代研究操作系统中，这种功能划分不只是逻辑上的：文件系统和网络协议等服务实现为核心或内核的客户应用程序进程。

4.3BSD 内核没有划分成多个进程。这是 UNIX 最早版本的一项基本设计决策。Ken Thompson 的头两个实现完全没有内存映射，因而在用户空间与内核空间之间也没有硬件强制的区分 \[Ritchie, 1988]。当时实现一个消息传递系统与实际实现的“内核 + 用户进程”模型一样容易。选择后者是为了简单，何况早期内核很小。正是越来越多的设施（如联网）进入内核，才把分离这些设施到用户进程变成一个诱人的前景——例如 Mach \[Accetta et al., 1986] 就在朝这个方向努力。

**多道程序设计**

UNIX 支持透明的多道程序设计——多个进程或程序并发执行的假象。这靠上下文切换（context switching）做到，即在进程的执行上下文之间切换。系统还提供调度（scheduling）进程执行的机制，即决定下一个执行谁；也提供设施，保证对进程间共享的数据结构的一致访问。

上下文切换是依赖硬件的操作，其实现受底层硬件设施影响。有些体系结构提供保存和恢复进程硬件执行上下文的机器指令，但内核使用的软件状态也必须一并切换。

上下文切换发生频繁，所以提高上下文切换的速度能显著减少花在内核里的时间，为执行用户应用腾出更多时间。上下文切换的大部分工作花在保存和恢复进程的操作上下文上，因此减少该上下文所需的信息量是产生更快上下文切换的有效途径。许多 UNIX 系统避免复制驻留进程的上下文状态，而是用存储管理硬件（若可用）把新运行进程的 user 结构映射到 user 结构的预期位置。这种映射也可以用软件经间接结构引用完成，但那样效率较低。

**调度**

公平的进程调度是一项复杂的任务，取决于可执行程序的类型和调度政策的目标。程序按其计算量和 I/O 量来刻画。调度政策通常要在资源利用与程序完成时间之间求平衡。进程的优先级根据它使用的 CPU 时间量、占有或执行所需的内存资源量等参数周期性重算。

UNIX 使用基于优先级的调度政策，偏向文本编辑器等交互式程序（interactive program），冷落长时间运行的批处理型作业。交互式程序往往表现为短促的计算爆发加一段不活动或 I/O。调度政策起初给每个进程较高的执行优先级，允许它执行一个固定的时间片（time slice）。用满时间片的进程优先级被降低，而让出 CPU 的进程（通常因为做 I/O）保持原优先级。不活动的进程优先级被提高。于是，大量消耗 CPU 时间的作业迅速沉到低优先级，而大部分时间不活动的交互式作业保持高优先级，一旦就绪就能抢占长时间运行的低优先级作业。交互式作业（如文本编辑器搜索字符串）可能短暂变成计算密集型而拿到较低优先级，但再次不活动时又会回到高优先级。

系统还需要一种调度政策来对付主存装不下所有想执行的进程的执行上下文而产生的问题。这种调度政策的主要目标是最小化抖动（thrashing）——内存短缺到系统处理缺页和调度进程的时间超过在用户态执行应用代码的时间时发生的现象。

系统必须既检测又消除抖动。检测靠观察空闲内存量和内存请求速率：空闲页很少而新内存请求的速率很高时，系统认为自己正在抖动。消除抖动的办法是找出四个最大的进程，把其中在内存驻留最久的换出。换出进程释放的内存可分给其余进程，后者通常就能继续了。这一选择标准偏向小的交互式作业，冷落大的批作业。若抖动继续，再选出更多进程换出，直到腾出足够的内存让其他进程有效运行。最终，足够的进程完成并释放内存，被换出的进程得以回到主存运行。不过，即使内存仍不足，被换出的进程在大约 20 秒后也会被允许回来。通常抖动会卷土重来，但换入的进程不再拥有最长驻留时间，于是会有别的进程被选中换出。

调度政策偏向交互式作业组合，反映出 UNIX 最初为分时环境使用而做的设计。关于替代调度政策（批处理环境或实时系统所用者）的论文不胜枚举。这些政策通常除修改调度政策外，还需要改动系统。

以下各节描述 4.3BSD 内核提供的服务，并给出这些服务设计的概貌。后续各章将描述这些服务在 4.3BSD 中的详细设计与实现。4.2 节详述进程的状态，包括 proc 和 user 结构。4.3 节描述上下文切换的设施，以及内核上下两半都要使用的系统数据结构的访问同步。4.4 节解释前述基于优先级的调度算法的实现。4.5 节讲进程创建，4.6 节讲进程终止。


---

# 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/2.1.-unix-she-shi-yu-nei-he.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.