RichardYi's Notebook

Homework2-解答

18 min read

OS-HW-2解答

一、选择题

  1. C

分析：操作系统提供的基本服务包括程序执行、I/O 操作、文件系统操作、通信、错误检测等；“软件模式设计”不属于操作系统基本服务。

  1. B

分析：Shell 的主要作用是作为用户和操作系统之间的接口，接收、解释并执行用户命令。

  1. A

分析：系统调用是用户程序向操作系统请求服务的编程接口，是用户态进入内核态获取服务的主要方式。

  1. C

分析：创建、终止、装入、执行进程等都属于进程控制（process control）类系统调用。

  1. B

分析：单体内核通常让大部分核心功能运行在同一内核地址空间中，因此执行效率较高，但模块边界较弱、故障影响范围较大。

  1. A

分析：微内核通常只保留最基本功能，如线程/进程管理、地址空间管理和进程间通信，其他服务尽量放到用户态。

  1. B

分析：分层结构按层次组织系统功能，上层建立在下层提供的服务之上，层与层之间有相对清晰的依赖关系。

  1. B

分析：可加载内核模块兼顾了“内核态执行效率”和“按需扩展”的模块化优势，不必每次都重编整个内核。

  1. A

分析：虚拟机的核心是对底层硬件进行抽象和复用，使多个操作系统实例可以共享同一套物理资源。

  1. B

分析：系统启动时由引导程序先完成基本初始化，再把操作系统内核装入内存并交给内核运行。

二、简答题

1. 教材中将操作系统的服务分为“面向用户的便利服务”和“面向系统高效运行的服务”。请分别列举至少三项，并说明二者关注点的差异。

（1）面向用户的便利服务

这类服务强调“让用户和应用更容易使用计算机系统”，常见包括：

  • 程序执行：负责把程序装入内存、启动执行、正常结束或异常终止。

  • I/O 操作：为程序访问键盘、显示器、磁盘、网络等设备提供统一接口。

  • 文件系统操作：支持创建、删除、读写、重命名文件和目录。

  • 通信：支持进程之间交换数据，可以是共享内存，也可以是消息传递。

  • 错误检测：检测 CPU、内存、I/O 设备和程序执行中的错误并作出处理。

  • 用户界面：如命令行界面、图形界面、Shell 等，为用户提供交互入口。

（2）面向系统高效运行的服务

这类服务强调“让整个系统资源使用更高效、更安全、更可控”，常见包括：

  • 资源分配：在多个用户和多个进程之间分配 CPU、内存、I/O 设备和存储空间。

  • 记账/统计：记录资源使用情况，例如 CPU 时间、内存占用、I/O 使用量，便于审计与优化。

  • 保护与安全：限制非法访问，保护进程、文件、内存和设备，确保系统稳定可靠。

（3）二者关注点的差异

面向用户的便利服务，核心是“好不好用”，重点在于为用户和应用程序提供方便、统一、易理解的操作方式。

面向系统高效运行的服务，核心是“管得好不好、跑得稳不稳、资源用得值不值”，重点在于整体资源管理、隔离、安全和系统效率。前者更偏向服务体验，后者更偏向系统治理。

2. 什么是系统调用接口（API 与 system-call interface 的关系）？请说明应用程序、API、运行时库和内核之间的大致关系。

系统调用接口可以理解为“用户程序进入内核请求操作系统服务的边界”。其中，API 是程序员在源代码里直接调用的接口，而 system-call interface 是这些请求真正进入内核时经过的底层边界。应用程序通常不会直接写底层陷入内核的指令，而是先调用 API，再由运行时库或系统库把请求转换为具体系统调用。

它们之间的大致关系如下：

  1. 应用程序（Application）

开发者编写的普通用户程序，例如文本编辑器、浏览器、编译器等。应用程序希望访问文件、创建进程、分配资源时，需要请求操作系统提供服务。

  1. API（Application Programming Interface）

API 是应用开发者直接面对的编程接口，例如 POSIX API、C 标准库中面向操作系统服务的接口、Win32 API 等。它通常比系统调用本身更友好、更可移植，也不一定与系统调用一一对应。

  1. 运行时库 / 系统库（Runtime Library / System Library）

运行时库负责提供 API 的具体实现。例如 C 程序中的 open()、read()、write() 等函数，往往由标准库或系统库进一步封装实际的系统调用。它会负责整理参数、执行必要检查，并触发从用户态到内核态的切换。

  1. System-call interface（系统调用接口）

这是用户态和内核态之间真正的入口边界。库函数最终通过软中断、陷入指令或其他体系结构支持的机制进入内核，把请求交给内核中的相应服务例程。

  1. 内核（Kernel）

内核接收到系统调用后，根据系统调用号和参数执行具体操作，例如打开文件、创建进程、分配内存、收发数据等，再把结果返回给用户程序。

可以把这条链路概括为：

应用程序 → API → 运行时库/系统库 → system-call interface → 内核服务例程

需要特别说明的是：

  • API 不等于 system call。API 是给程序员使用的编程接口，system call 是进入内核的底层机制。

  • 一个 API 可能对应一个或多个系统调用，也可能完全在用户态完成。

  • 程序员通常接触 API，操作系统真正执行服务依赖系统调用接口。

3. 请简述分层操作系统结构的优点与局限性。你认为在教学操作系统中采用分层设计有什么价值？

分层操作系统结构（Layered Approach）是把操作系统划分为若干层，每一层只依赖其下层提供的功能，并向上层提供抽象服务。

优点：

  1. 结构清晰，便于理解

各层职责相对明确，系统组织方式比完全混杂的结构更容易分析和学习。

  1. 模块化较好，便于维护

某一层的实现发生变化时，只要接口保持稳定，对其他层影响相对有限。

  1. 更利于调试与验证

可以按层检查问题，便于定位错误，也更适合逐层构建和测试。

  1. 有助于信息隐藏和抽象

上层不需要了解下层实现细节，只需要依赖下层提供的服务接口。

局限性：

  1. 严格分层不容易设计

现实中的操作系统功能往往相互交织，很难把所有功能都完全整齐地划分到独立层次中。

  1. 可能带来性能开销

如果请求必须逐层传递，可能增加额外的函数调用、检查和上下文处理成本。

  1. 灵活性可能受限

某些功能若跨层协作很强，严格分层可能使实现变得绕远，降低工程灵活性。

  1. 层间接口设计要求高

如果接口划分不合理，后续扩展会比较困难，甚至导致“表面分层、实际耦合”。

在教学操作系统中的价值：

我认为分层设计在教学操作系统中非常有价值。首先，它能把复杂的操作系统拆成若干可讲解、可实验、可验证的模块，帮助学生建立从硬件到内核服务再到用户接口的整体认识。其次，教学场景更强调“概念清晰”和“结构可解释”，分层设计正适合展示抽象、封装和依赖关系。最后，学生在实现简化版操作系统时，按层推进更容易控制复杂度，也更容易发现自己到底在哪一层出了问题。因此，即使现实操作系统未必严格分层，分层设计仍然是教学中非常有效的组织方法。

三、分析题

1. 某教学实验系统准备增加一个新的文件压缩服务。现有两种方案：（a）把压缩功能直接编入内核；（b）把压缩服务放到用户态，通过系统调用与内核交互。请从安全性、性能、可维护性三个角度分析两种方案的差异，并说明在什么场景下你更倾向于选择哪一种方案。

这个问题的核心在于：压缩服务究竟应该作为“内核内部能力”还是“用户态系统服务”存在。二者都能实现功能，但设计取舍非常不同。

（1）安全性比较

方案（a）：直接编入内核

  • 压缩代码运行在内核态，权限最高。

  • 一旦压缩模块存在 bug，例如越界访问、空指针、整数溢出，就可能直接导致内核崩溃，严重时带来提权或破坏系统完整性的风险。

  • 内核攻击面扩大后，问题影响范围是全系统级别。

方案（b）：放在用户态，通过系统调用交互

  • 压缩服务运行在用户态，权限受限，即使服务进程崩溃，通常也不会直接把内核拖垮。

  • 借助进程隔离、权限控制、沙箱机制，可以更容易限制该服务的影响范围。

  • 从系统整体安全角度看，用户态方案通常更稳健。

**结论：**从安全性看，用户态方案通常更优，因为它更符合最小权限原则，故障隔离能力更强。

（2）性能比较

方案（a）：直接编入内核

  • 内核内部调用路径更短，可能减少用户态/内核态切换开销。

  • 如果压缩服务与内核中的文件系统、页缓存或 I/O 路径深度结合，内核态实现可能获得更高效率。

  • 对高频、低延迟、强耦合场景，内核实现可能具备性能优势。

方案（b）：放在用户态，通过系统调用交互

  • 需要系统调用、上下文切换以及可能的数据拷贝，因此存在额外开销。

  • 如果压缩的数据量很大、调用很频繁，这些开销可能变得明显。

  • 但对于一般教学系统或普通应用场景，这部分开销往往是可以接受的。

**结论：**从纯性能角度看，内核态方案可能更快，尤其是在压缩服务位于关键 I/O 路径上时更明显。

（3）可维护性比较

方案（a）：直接编入内核

  • 内核代码开发要求高，调试困难，测试成本大。

  • 修改和升级往往更麻烦，稍有不慎就会影响系统整体稳定性。

  • 压缩算法若需要频繁迭代，放在内核中会使维护负担明显增加。

方案（b）：放在用户态，通过系统调用交互

  • 开发、调试、替换和升级都更方便。

  • 服务可以独立发布和更新，不必频繁改动内核。

  • 更容易采用模块化、面向服务的设计思路，也更适合教学实验中的反复修改与验证。

**结论：**从可维护性看，用户态方案明显更优。

（4）我的倾向与适用场景

我会分场景选择：

更倾向选择内核态方案（a）的场景：

  • 压缩功能处于关键数据通路，性能要求极高；

  • 需要与文件系统、缓存管理或块设备层深度集成；

  • 功能稳定、边界清晰、经过严格验证，且系统对性能的要求显著高于可维护性。

例如：某些高性能存储系统中的透明压缩，可能更适合放到内核关键路径中实现。

更倾向选择用户态方案（b）的场景：

  • 教学实验系统、原型系统或需要频繁迭代的项目；

  • 对安全隔离和维护便利性要求较高；

  • 压缩功能不是极端性能敏感的核心路径。

对于题目中的“教学实验系统”，我更倾向于选择方案（b），即把压缩服务放在用户态。原因是：教学环境更强调结构清晰、调试方便、风险可控和便于修改，而不是榨取极限性能。把压缩服务放到用户态，更能体现现代操作系统设计中“机制与策略分离、最小权限、模块化”的思想，也更适合学生理解与实验。

说明

  • 已完成：选择题 1–10、简答题 1–3、分析题 1。

  • 按要求未作答：分析题 2（eBPF/XDP 实验复现题）。

参考

  1. Abraham Silberschatz, Peter B. Galvin, Greg Gagne, Operating System Concepts (9th Edition), Chapter 2: Operating-System Structures.

  2. Operating System Concepts companion site: https://os-book.com/OS10/index.html

  3. OSTEP (Operating Systems: Three Easy Pieces): https://pages.cs.wisc.edu/~remzi/OSTEP/

  4. Linux man-pages project, system call overview and related entries: https://www.kernel.org/doc/man-pages/ , https://man7.org/linux/man-pages/man2/fork.2.html , https://man7.org/linux/man-pages/man2/execve.2.html

Graph View