系统调用：用户态与内核态

概念

系统调用（system call）是操作系统内核提供给应用程序的、请求内核服务的唯一受控入口。

$$\text{应用程序}\stackrel{\text{系统调用}}{\to }\text{操作系统内核}\stackrel{\text{特权指令 / 驱动}}{\to }\text{硬件}$$

一句话说清它是什么：系统调用就是"用户程序按门铃的唯一那只按钮"——用户程序不能直接碰硬件（那是特权），只能通过这只按钮请内核代劳；而内核通过控制"哪些按钮存在、按下后做什么"来保证安全。

★ 这是整条主线【由硅到 C】的收束点。前面所有课程都在回答"硬件怎么工作"，这一章回答"应用程序到底怎么让硬件为它工作"。答案就是四个字：陷入内核。

原理

一、为什么必须有系统调用

三条理由，缺一不可：

理由	说明	反例
保护	硬件资源必须被"集中管控"，否则一个恶意程序就能毁掉整个系统	若无两态，程序可直接执行"清内存"指令
抽象	应用程序不该关心"磁盘是 SATA 还是 NVMe、扇区多大"	直接写磁盘控制器寄存器 = 每种硬盘都要改程序
统一	同一份代码要在不同硬件上跑，必须有统一接口	不同厂商的网卡寄存器布局完全不同

回顾第 os/01-overview.md 的结论：两态靠 PSW 的模式位 区分，修改 PSW 本身是特权指令——所以用户程序无法自己"提权"。那么问题就来了：

用户程序既不能自己提权，又不能直接碰硬件，它怎么让硬件为它干活？

答案：留一条受控的、唯一的门——陷阱指令（trap）。用户主动"跳进去"，硬件负责"切态"，内核负责"判断请求是否合法"。

二、系统调用的完整过程（本章核心）

用户态                                        内核态
─────────────────────────────────────────────────────────────────
① 准备参数
   (MIPS: $v0 = 服务号, $a0~$a3 = 参数)
        │
② 执行陷阱指令 syscall / int 0x80 / svc
        │
        └──► ★ 硬件介入，一键完成"切态" ──►
                                              ③ 保存现场
                                                 (PSW、PC、通用寄存器)
                                              ④ PSW 模式位 <- 内核态
                                              ⑤ 按"服务号"查系统调用表
                                                 得到内核例程入口地址
                                              ⑥ 执行内核例程
                                                 (可能再调用驱动)
                                              ⑦ 返回值放回约定寄存器
                                                 (MIPS: $v0)
                                              ⑧ 恢复现场, PSW 模式位 <- 用户态
        ◄──────────────────────────────────────┘
⑨ 继续执行下一条指令 (返回值已在 $v0)

逐条说清几个关键点：

步骤	谁做的	关键细节
① 准备参数	用户程序	通过寄存器（最快）或栈传递；MIPS 约定 $v0 放服务号
② 执行陷阱指令	用户程序	陷阱指令本身是非特权指令——否则用户永远无法请求服务
③ 保存现场	硬件	与中断隐指令同一套机制（见 arch/33-exception.md）
④ 切到内核态	硬件	修改 PSW 模式位——用户程序自己做不到，只能靠陷阱触发硬件来做
⑤ 查系统调用表	内核	一张"服务号 → 内核例程地址"的表；服务号是索引，不是地址
⑥ 执行内核例程	内核	这里才是真正的"干活"（可能再去操作硬件）
⑦ 返回结果	内核	MIPS 约定放 $v0；x86-64 约定放 rax
⑧ 恢复现场 + 切回用户态	硬件 + 内核	回去后执行下一条指令（自陷 trap 的返回语义）

⚠️ 三个易错点：

1. 陷阱指令必须是非特权指令（用户能执行），但它导致的结果（进入内核态）是特权行为——这是"唯一合法越界门"的含义。
2. 切态由硬件完成，不是内核"自己换衣服"——因为改 PSW 是特权指令，内核态的代码根本不需要"提权"，是用户态那一步需要一个硬件机制去打破两态边界。
3. 系统调用的返回地址是"下一条指令"（自陷 trap 的语义），不是重新执行 syscall——否则就死循环了。这与"缺页（故障 fault）返回后重执行 lw"形成鲜明对照。

三、系统调用的六大分类

类别	典型服务	例子（Linux 系统调用名）
设备管理	申请/释放设备、启动 I/O、读写设备	open、close、read、write、ioctl
文件管理	创建/删除/读写/定位文件	open、creat、unlink、lseek、stat
进程控制	创建/撤销/阻塞/唤醒/切换	fork、execve、exit、wait、kill
进程通信	消息传递、共享内存、管道	pipe、shmget、mmap、msgget
内存管理	申请/释放内存、修改地址空间	brk、mmap、munmap
信息维护	取时间、取系统参数、设权限	getpid、alarm、chmod、uname

注意 open 同时属于"设备管理"和"文件管理"——分类是按功能视角划的，不是按"一个调用只归一类"。答题时看题干问的是哪个视角。

四、API、库函数、系统调用：三者不是一回事

层次	例子	是否一定产生系统调用
API / 库函数（用户态，libc 提供）	printf、malloc、fopen、strlen	不一定
系统调用（内核态入口）	write、brk、open	是（它就是入口）

四个经典对照（必记）：

库函数	内部实际发生的事
strlen(s)	纯用户态计算，完全不进内核
printf("a")	写入 stdio 缓冲区；缓冲区满了才调用 write —— 可能不进内核！
malloc(16)	纯用户态操作堆（除非堆不够，才调用 brk/mmap）
fopen / fread	库函数包了一层缓冲，底层必然调用 open/read

⚠️ 这是概念题的高频陷阱："调用了库函数" ≠ "发生了系统调用"。printf 在缓冲没满时一次内核都不进——这正是下面例 2 里"快 4096 倍"的根源。

反过来也要注意：不能直接调用系统调用 "绕过" 库函数的缓冲会带来性能灾难（例 2），因为"缓冲"本来就是为"摊薄系统调用开销"而存在的。

五、MIPS32 与 x86-64 的落地对照

MIPS32（本站统一口径，MARS 约定）：

项	约定
陷阱指令	syscall，机器码 0x0000000C（R 型，opcode = 0，funct = 0x0C）
服务号寄存器	$v0（进内核前放服务号，返回后放返回值）
参数寄存器	$a0 ~ $a3（最多 4 个参数）
服务号表	MARS 表：1 打印整数 / 4 打印字符串 / 5 读整数 / 8 读字符串 / 9 sbrk 堆分配 / 10 exit 退出

x86-64（对照附录）：

项	约定
陷阱指令	syscall（现代）/ int 0x80（32 位遗留）
服务号寄存器	rax
参数寄存器	rdi、rsi、rdx、r10、r8、r9
服务号表	Linux x86-64：0 read / 1 write / 2 open / 3 close / 57 fork / 59 execve / 60 exit

口径提醒：Linux/MIPS o32 ABI 的服务号是 4000 + n 的形式（write = 4004），错误靠 $a3 ≠ 0 判断——这只是"另一种 ABI 的编号",与 MARS 表不冲突。本站正文一律用 MARS 表口径（与 lang/05-syscall.md 对齐）。

六、中断、异常、系统调用：三个入口，一个机制

项	触发者	触发时机	与当前指令的关系	返回地址
中断（外中断）	外部设备	随机、异步	无关	下一条指令
异常（故障 fault）	指令执行出错	同步	就是这条指令	当前指令（重执行）
系统调用（自陷 trap）	指令主动请求	同步	就是这条指令	下一条指令

三者的共同点：都通过"陷阱机制"进入内核、都要切态、都要保存/恢复现场。

$$\text{中断}\cup \text{异常}\cup \text{系统调用}⟹\text{同一个"陷入内核"的硬件机制}$$

这就是为什么"系统调用"常常被写成"访管中断"或"软中断"——它在外观上确实像一次中断（都有保存现场、切态、跳转），区别只在"是谁引起的"：外部设备引起的叫中断，程序自己 syscall 引起的叫系统调用。

七、系统调用的开销与"缓冲"的意义

系统调用的开销来自三块：

1. 模式切换（用户态 ↔ 内核态），要做权限检查、切换栈、刷新流水线
2. 上下文保存与恢复（寄存器、PSW）
3. 内核例程本身的执行（可能还要访问硬件）

量级对比（现代 x86-64，仅供数量级参考）：

操作	量级
用户态函数调用	几 ns
getpid()（现代 vDSO 快路径，不进内核）	几十 ns
read / write 到管道	几百 ns
fork	几十 μs
exit	几 μs

结论：系统调用比用户态函数调用慢 1~3 个数量级。 这直接引出一条工程铁律：

$$\mathbf{\text{减少系统调用次数}}\gg \text{优化内核例程}$$

具体手段：缓冲（把多次小调用合成一次大调用）、批量（readv/writev）、内存映射（mmap 替代大量 read）。例 2 会量化"缓冲"到底值多少。

示例

例 1：一次"打印一行字"的完整链路

用户在 MIPS32 上执行 printf("Hello\n")。请写出从 C 代码到"字符出现在屏幕上"的完整链路，并指出每一步发生在用户态还是内核态。

完整链路：

步	层	动作	状态
1	C / libc	printf 把 "Hello\n" 拷进 stdio 缓冲区	用户态
2	libc	遇到 \n 且是终端 → 冲刷缓冲区 → 调用 write(1, buf, 6)	用户态
3	libc	write 是一条包装（wrapper）：把服务号放进 $v0，参数放进 $a0~$a3	用户态
4	硬件	执行 syscall（0x0000000C）→ 保存现场 + PSW 切到内核态	切态（硬件）
5	内核	按 $v0 的服务号查系统调用表，找到 sys_write 例程	内核态
6	内核	sys_write 校验缓冲区地址（用户传进来的地址必须在内核认可的范围），找到文件描述符 1 对应的终端设备	内核态
7	内核	调用终端驱动，把 6 个字节写进设备寄存器（这一步才真的是"硬件操作"）	内核态
8	硬件	终端把字节显示在屏幕上（异步，CPU 不等）	硬件
9	内核	把写入字节数放回 $v0，恢复现场 + PSW 切回用户态	切态（硬件）
10	C	继续执行 printf 后面的语句	用户态

核对本题的关键数字："Hello\n" 共 6 字节（5 个可见字符 + 1 个换行），所以 write 的长度参数是 6。

⚠️ 四个必须说清的点：

1. 第 1~3 步全在用户态——printf 是库函数，不是系统调用。只有第 4 步的 syscall 才是系统调用。
2. 第 4 步的"保存现场 + 切态"由硬件完成——这就是"陷阱指令"与普通跳转（j/jal）的本质区别：普通跳转不切态。
3. 第 6 步的地址校验是系统调用的安全核心——用户传的指针必须被内核验证过才能解引用，否则用户就能拿 write(fd, 0x0, 4) 读内核数据。
4. 第 7 步才碰硬件——用户程序从头到尾没有直接操作过设备寄存器，这正是"保护"的含义。

例 2：缓冲到底值多少——系统调用次数决定性能

某程序要向文件输出 1 MiB 数据。一次 write 系统调用的开销（含模式切换与内核例程）约 500 ns。对比两种写法：（a）每字节调用一次 write；（b）4 KiB 缓冲，缓冲满了一次 write。

完整计算过程：

第一步，数据总量与缓冲划分：

$$N=1\text{MiB}=1024\times 1024=1048576\text{B}$$$$\text{缓冲块数}=\frac{1048576\text{B}}{4096\text{B/块}}=256\text{块}$$

第二步，方案（a）逐字节：调用次数 = 1 048 576 次

$$T_a=1048576\times 500\text{ns}=524288000\text{ns}$$$$T_a=\frac{524288000}{{10}^9}\text{s}=\mathbf{0.524}\mathbf{s}$$

第三步，方案（b）4 KiB 缓冲：调用次数 = 256 次

$$T_b=256\times 500\text{ns}=128000\text{ns}=\mathbf{0.128}\mathbf{ms}$$

第四步，加速比：

$$\frac{T_a}{T_b}=\frac{524288000\text{ns}}{128000\text{ns}}=\mathbf{4096}$$

第五步，省掉的模式切换次数：

$$1048576-256=\mathbf{1}\mathbf{048}\mathbf{320}\text{次}$$

结果汇总：

方案	write 调用次数	总耗时	相对
(a) 逐字节	1 048 576	0.524 s	1.00×
(b) 4 KiB 缓冲	256	0.128 ms	快 4096 倍

结论：同一份数据、同一块磁盘、同一份内核代码，只因为"调用了 4096 倍少的系统调用"，快了 4096 倍。

这个数字就是 libc 存在的意义。标准库的 stdio 缓冲、std::ostream 缓冲、Python 的 io.BufferedReader、Java 的 BufferedWriter——全都只是为了同一件事：把小的 write 攒成大的 write。

反过来看："系统调用慢"这个事实不是缺点，而是设计代价——"慢"是因为每次都要做权限校验与切态，而正是这些校验保证了安全。想快，就别频繁越界；想越界，就必须付钱。

例 3：MIPS32 对比 x86-64——同一个"退出"的两种写法

用 MIPS32 与 x86-64 各写一段"打印一行并退出"的程序，对照两者的寄存器约定。

MIPS32（本站统一口径，MARS 约定）：

.data
msg:    .asciiz "Hello, kernel\n"

.text
.globl main
main:
        li      $v0, 4          # 服务号 4 = print_string
        la      $a0, msg        # 参数 1: 字符串地址
        syscall                 # 陷入内核, 机器码 0x0000000C

        li      $v0, 10         # 服务号 10 = exit
        syscall                 # 再一次陷入内核

x86-64（对照附录，Linux）：

        .section .rodata
msg:    .ascii "Hello, kernel\n"

        .text
        .globl _start
_start:
        mov     $1, %rax        # 服务号 1 = write
        mov     $1, %rdi        # 参数 1: fd = 1 (stdout)
        lea     msg(%rip), %rsi # 参数 2: 缓冲区地址
        mov     $14, %rdx       # 参数 3: 长度 14 字节 (必须自己数对!)
        syscall                 # 陷入内核 (机器码 0x0F 0x05)

        mov     $60, %rax       # 服务号 60 = exit
        xor     %rdi, %rdi      # 参数 1: 退出码 0
        syscall

对照表：

对比项	MIPS32（MARS 约定）	x86-64（Linux 约定）
陷阱指令	syscall	syscall
机器码	0x0000000C	0x0F 0x05（2 字节）
服务号寄存器	$v0	%rax
参数寄存器	$a0、$a1、$a2、$a3	%rdi、%rsi、%rdx、%r10、%r8、%r9
返回值	$v0	%rax
打印字符串的服务号	4	1（write）
退出的服务号	10	60
一条指令打印整串？	可以（服务号 4 直接收字符串地址）	不能（只有 write，需自己给长度）

⚠️ 关键差异：

• MIPS 的 syscall 是 R 型指令（opcode = 0），所以机器码 0x0000000C 的高 26 位全 0、只有 funct 字段是 0x0C。
• MARS 的"服务号 4 = print_string"是模拟器提供的便利，相当于把"算长度 + 调 write"打包了；真实 OS 的 ABI 里没有"打印字符串"这种系统调用。
• "Hello, kernel\n" 的长度必须精确数对：

$$\underset{Hello}{\underbrace{5}}+\underset{,}{\underbrace{1}}+\underset{\text{空格}}{\underbrace{1}}+\underset{kernel}{\underbrace{6}}+\underset{\text{换行}}{\underbrace{1}}=\mathbf{14}\text{字节}$$

x86-64 的 write 只有长度、没有"字符串"概念——数错一个字节，输出就会多一个或少一个字符。这正是"抽象层次不同"的直接体现：MARS 帮你数，Linux 让你自己数。

例 4：C 实现——系统调用开销与缓冲的量化对照

把例 2 的账算清楚，并加上"设备提速"的敏感度分析。

#include <stdio.h>

/* 系统调用开销与缓冲效果估算
 * 口径: 一次 write 系统调用(含模式切换)约 500 ns
 *       库函数(用户态)调用约 5 ns
 */
#define DATA_BYTES   (1 << 20)   /* 1 MiB */
#define SYSCALL_NS   500         /* 单次 write 开销 */
#define LIBCALL_NS   5           /* 单次用户态函数调用 */
#define BUF_BYTES    4096        /* 缓冲区大小 */

int main(void) {
    long n_unbuf = DATA_BYTES;               /* 逐字节 */
    long n_buf   = DATA_BYTES / BUF_BYTES;   /* 4 KiB 缓冲 */

    /* 只算"系统调用"这一项开销; 数据拷贝等成本此处不计 */
    double t_unbuf = (double)n_unbuf * SYSCALL_NS;   /* ns */
    double t_buf   = (double)n_buf   * SYSCALL_NS;   /* ns */

    printf("数据 %d B\n", DATA_BYTES);
    printf("逐字节 write : %ld 次 x %d ns = %.0f ns = %.3f s\n",
           n_unbuf, SYSCALL_NS, t_unbuf, t_unbuf / 1e9);
    printf("4 KiB 缓冲   : %ld 次 x %d ns = %.0f ns = %.3f ms\n",
           n_buf, SYSCALL_NS, t_buf, t_buf / 1e6);
    printf("快 %.0f 倍, 少切换 %ld 次\n", t_unbuf / t_buf, n_unbuf - n_buf);

    /* 量级对比: 用户态函数调用 vs 系统调用 */
    printf("--- 量级对比 ---\n");
    printf("用户态函数调用 %d ns vs 系统调用 %d ns -> 慢 %.0f 倍\n",
           LIBCALL_NS, SYSCALL_NS, (double)SYSCALL_NS / LIBCALL_NS);

    /* 敏感度: 若换成 64 KiB 缓冲 */
    long n_big = DATA_BYTES / 65536;
    printf("--- 换成 64 KiB 缓冲 ---\n");
    printf("调用 %ld 次, 耗时 %.0f ns = %.3f ms (相对 4 KiB 再快 %.0f 倍)\n",
           n_big, (double)n_big * SYSCALL_NS,
           (double)n_big * SYSCALL_NS / 1e6, (double)n_buf / n_big);
    return 0;
}

c 本站为静态站，不提供在线运行；可复制到本地用 gcc / python 执行

预期输出：

数据 1048576 B
逐字节 write : 1048576 次 x 500 ns = 524288000 ns = 0.524 s
4 KiB 缓冲   : 256 次 x 500 ns = 128000 ns = 0.128 ms
快 4096 倍, 少切换 1048320 次
--- 量级对比 ---
用户态函数调用 5 ns vs 系统调用 500 ns -> 慢 100 倍
--- 换成 64 KiB 缓冲 ---
调用 16 次, 耗时 8000 ns = 0.008 ms (相对 4 KiB 再快 16 倍)

三个结论：

1. 系统调用比用户态函数调用慢 100 倍（500 ns vs 5 ns）——这就是"能不进内核就不进"的原因。
2. 缓冲把开销从 0.524 s 压到 0.128 ms（4096 倍），而代码逻辑几乎没变——只是把"一次写一个字节"改成"攒够 4 KiB 再写"。
3. 缓冲不是越大越好：64 KiB 缓冲把调用次数从 256 降到 16（再快 16 倍），但代价是——数据积压在缓冲区里，用户看到的延迟变长（"最后不满一块的数据要等缓冲区满或显式 fflush 才出去"）。这正是 printf 不加 \n 时"看不到输出"的原因。

(double)n_unbuf * SYSCALL_NS 里的 (double) 很关键：n_unbuf 是 long（1 048 576），若写成 n_unbuf * SYSCALL_NS，结果是 long × int → long，在 64 位平台上不会溢出；但在 32 位 long（Windows/LLP64 下 long 是 32 位）上，最大只能表示约 21.5 亿——本例 524 288 000 侥幸没超，但换成 4 MiB 数据（2 097 152 × 500 = 1 048 576 000）就逼近上限了。先转 double 是最省心的做法。

例 5：Python——系统调用开销与缓冲全表验算

# ===== 例 1: 各类调用的耗时量级 =====
print('=== 例 1: 各类调用的耗时量级 ===')
for name, ns in [('用户态函数调用', 5), ('getpid (vDSO 快路径, 不进内核)', 60),
                 ('read/write 到管道', 500), ('exit', 3000), ('fork', 40000)]:
    print('  %-32s ~ %6d ns = %8.3f us' % (name, ns, ns / 1000))
print('  -> 系统调用比用户态函数调用慢 1~3 个数量级')

# ===== 例 2: 缓冲 vs 逐字节 write =====
print('\n=== 例 2: 1 MiB 数据, 每次 write 500 ns ===')
DATA, WC, BUF = 1 << 20, 500, 4096
n_unbuf, n_buf = DATA, DATA // BUF
t_unbuf, t_buf = n_unbuf * WC, n_buf * WC
print('  逐字节 write: %d 次 x %d ns = %d ns = %.3f s' % (n_unbuf, WC, t_unbuf, t_unbuf / 1e9))
print('  4 KiB 缓冲  : %d 次 x %d ns = %d ns = %.3f ms' % (n_buf, WC, t_buf, t_buf / 1e6))
print('  快 %d 倍, 少切换 %d 次' % (t_unbuf // t_buf, n_unbuf - n_buf))

print('\n=== 例 2 敏感度: 缓冲大小的影响 ===')
for buf in [1, 64, 512, 4096, 65536, 1 << 20]:
    n = DATA // buf
    t = n * WC
    print('  缓冲 %8d B -> %8d 次调用, %12d ns = %10.4f ms' % (buf, n, t, t / 1e6))
print('  -> 缓冲越大, 次数越少; 但延迟越大 (数据积压在缓冲区)')

# ===== 例 3: 机器码与寄存器约定 =====
print('\n=== 例 3: 陷阱指令与寄存器约定 ===')
print('  MIPS32: 指令 syscall, 机器码 0x0000000C (R 型: opcode=0, funct=0x0C)')
print('          服务号 $v0 ; 参数 $a0-$a3 ; 返回值 $v0')
print('          MARS 服务号: 1 打印整数 / 4 打印字符串 / 5 读整数 / 8 读字符串 / 9 sbrk / 10 exit')
print('  x86-64: 指令 syscall, 机器码 0x0F 0x05')
print('          服务号 %rax ; 参数 %rdi %rsi %rdx %r10 %r8 %r9 ; 返回值 %rax')
print('          Linux 服务号: 0 read / 1 write / 2 open / 3 close / 57 fork / 59 execve / 60 exit')
print('  Linux/MIPS o32 对照口径: 服务号 = 4000 + n (write = 4004), 错误靠 $a3 != 0 判断')

print('\n=== 例 3 自检: 字符串长度 ===')
s = 'Hello, kernel\n'
print('  %r 的长度 = %d 字节 (可见字符 %d + 换行 1)'
      % (s, len(s), len(s) - 1))
print('  -> x86-64 用 write 必须自己给长度; MARS 的服务号 4 会自动数')

# ===== 库函数是否产生系统调用 =====
print('\n=== 库函数 / 系统调用 对照 ===')
for fn, kernel in [('strlen(s)', False), ('printf (缓冲未满)', False),
                   ('printf (缓冲满/含 \\n 冲刷)', True), ('malloc(16) (堆够)', False),
                   ('malloc (堆不够 -> brk/mmap)', True), ('fopen / fread', True)]:
    print('  %-28s 是否进内核: %s' % (fn, '是' if kernel else '否'))
print('  要点: 调用了库函数 != 发生了系统调用')

python 本站为静态站，不提供在线运行；可复制到本地用 gcc / python 执行

输出对照：例 1 得五档耗时（5 / 60 / 500 / 3000 / 40000 ns）；例 2 得逐字节 0.524 s vs 4 KiB 缓冲 0.128 ms，快 4096 倍、少切换 1 048 320 次；例 3 得 syscall 的机器码 0x0000000C（MIPS）与 0x0F 0x05（x86-64），"Hello, kernel\n" 长度 14 字节；库函数对照表确认"printf 缓冲未满时不进内核"。全部与手算一致。

一个值得单独记住的细节："Hello, kernel\n" 的准确长度是 14 字节（Hello 5 + , 1 + 空格 1 + kernel 6 + \n 1）。用 write 时长度完全由程序员负责——数错一个字节，输出就会多一个字符或少一个字符。 这是"库函数的便利"与"系统调用的原始"之间最直观的差距。

考点

考点

1. 必背结论

• 系统调用 = 用户程序请求内核服务的唯一受控入口；三大理由：保护、抽象、统一。
• 陷阱指令本身是非特权指令（用户能执行），但它导致"切到内核态"——唯一合法的越界门。
• 切态由硬件完成（改 PSW 模式位），不是内核自己提权——因为修改 PSW 本身是特权指令。
• 系统调用表按"服务号"索引，服务号是索引不是地址。
• 返回值放回约定寄存器（MIPS $v0 / x86-64 %rax），返回后执行下一条指令。
• 六大分类：设备管理、文件管理、进程控制、进程通信、内存管理、信息维护。
• 库函数调用 ≠ 系统调用：strlen 纯用户态；printf 缓冲未满时不进内核；malloc 堆够时不进内核。
• 中断 / 异常 / 系统调用三者共用同一套陷阱机制，区别只在"谁引起、返回哪里"。
• 系统调用比用户态函数调用慢 1~3 个数量级（例 2：500 ns vs 5 ns，慢 100 倍）。

2. 高频陷阱

• 说"陷阱指令是特权指令"：错。若它是特权指令，用户程序永远无法请求内核服务——那系统调用就不存在了。这是本考点第一大失分点。
• 说"系统调用返回后要重新执行该指令"：错。系统调用是自陷（trap），返回下一条指令；只有故障（fault，如缺页）才返回并重执行当前指令。
• 把 printf / malloc 直接当成系统调用：它们是库函数，只在特定条件下才调用系统调用。概念题常以"下列哪个一定是系统调用"的形式考。
• 说"系统调用是中断"：严格说不是。中断由外部设备引起、与当前指令无关；系统调用由指令主动发起。但两者共用陷阱入口——这就是它被叫"访管中断/软中断"的原因。答题要能说清"机制相同、来源不同"。
• 忘了"用户传指针必须被内核校验"：系统调用的安全核心之一就是校验用户传入的地址与参数。没有这一步，write 就能读内核内存。
• 把"服务号"当成"入口地址"：服务号是表索引，入口地址要查表得到。
• 把 MARS 的"服务号 4 打印字符串"当成真实 OS 的系统调用：MARS 是模拟器便利；真实的 Linux 只有 write，长度要自己给。
• write 的长度数错："Hello, kernel\n" 是 14 字节，不是 15。用 write 时长度是程序员的责任。
• "缓冲越大越好"：错。缓冲越大，调用次数越少，但数据积压越久、延迟越大；且最后不满一块的数据必须靠 fflush/fsync 强制出去（这正是 printf 不加 \n 时"看不到输出"的原因）。
• 以为"减少系统调用 = 绕过内核"：错。缓冲只是把多次小调用合并成一次大调用，该进内核还是要进，只是进得少了。

3. 解题模板（"系统调用链路题"）

① 从 C 语句出发, 判断它是不是系统调用
     库函数 -> 先看它的内部: 缓冲? 还是直接包装系统调用?
② 写清"用户态准备": 服务号放哪个寄存器、参数放哪几个
③ 陷阱指令: 写出指令名与机器码, 声明"硬件保存现场 + 切态"
④ 内核态: 查"服务号 -> 入口地址"的表, 执行内核例程
⑤ 安全校验: 地址是否合法、参数是否越权
⑥ 返回: 结果放哪个寄存器, 恢复现场 + 切回用户态, 返回"下一条指令"
⑦ 若问开销: 次数 x 单次开销; 若问优化: 谈缓冲/批量/mmap

4. 与相邻章节的接口

• os/01-overview.md（操作系统概述）：那篇讲"为什么需要两态"（靠 PSW 模式位区分，改 PSW 是特权指令），本篇讲"怎么合法地从用户态进内核态"——两篇合起来才是完整的"软硬交界"。
• arch/33-exception.md（异常与中断）：系统调用就是"自陷 trap"这一类的具体用途；那篇的"中断隐指令（关、存、引）"正是本篇第 ③④ 步的硬件细节。保存现场、切态、跳转——两篇是同一套机制。
• arch/30-datapath.md / arch/31-controller.md（数据通路 / 控制器）：syscall 这条指令在数据通路里怎么流、控制器怎么发出"切态 + 保存断点"的控制信号，都在那两篇。
• arch/41-io.md（I/O 系统）：系统调用最终要落到 I/O——read/write 内部要么走程序查询、要么走中断、要么走 DMA，那三种方式的取舍就是那篇的内容。
• lang/05-syscall.md（MIPS 汇编的系统调用）：那篇讲"怎么用"（$v0 放服务号、syscall 怎么写），本篇讲"为什么"（两态、陷阱、安全）。口径一致：MARS 服务号表 + syscall 机器码 0x0000000C。
• 下一章 os/10-process.md：系统调用里最重的一类是进程控制（fork/execve/exit）——它们要操作的对象是"进程"，而进程正是操作系统要管的第一样东西。

小结

• 系统调用 = 用户程序请求内核服务的唯一受控入口，存在三条理由：保护、抽象、统一。
• 完整链路九步：用户态准备（服务号 + 参数）→ 陷阱指令 → 硬件保存现场 + 切态 → 内核查表 → 校验参数 → 执行例程 → 返回结果 → 恢复现场 + 切回 → 执行下一条。
• 陷阱指令本身非特权，但它导致的切态是特权行为——这是"唯一合法越界门"的全部含义。
• 库函数 ≠ 系统调用：printf 缓冲未满时不进内核，malloc 堆够时不进内核——这是概念题的高频陷阱。
• 中断 / 异常 / 系统调用共用同一套陷阱机制，区别只在"谁引起、返回哪里"：系统调用返回下一条，缺页返回重执行。
• 系统调用比用户态函数调用慢 100 倍（500 ns vs 5 ns）；缓冲把它摊薄 4096 倍（例 2：0.524 s → 0.128 ms）——这就是 libc 缓冲、std::ostream、BufferedReader 存在的全部理由。
• MIPS32 口径：syscall = 0x0000000C，服务号在 $v0，参数在 $a0~$a3，MARS 表 1/4/5/8/9/10。

主线【由硅到 C】到此走完一整圈。回头看那条链：硅（晶体管）→ 电路（门与译码器）→ 机器（PSW、流水线、中断）→ 语言（$v0 与服务号、指针与栈）→ 系统（查表、校验、执行）。用户在 C 里写下的一行 printf，正是这条链上每一层同时工作的结果——而"系统调用"就是这条链最后的那一次握手：用户程序把请求交出去，操作系统把答案送回来。

下一篇：进程与线程：PCB、状态转换、上下文切换