【操作系统百科】Unix 谱系与设计遗产：Multics、Plan 9、Linux

你每天在终端敲的 ls | grep foo | wc -l，是 1972 年 Doug McIlroy 在贝尔实验室过道里对 Ken Thompson 吼了一嗓子的产物：“Shouldn’t it be possible to connect programs like a garden hose?” 那句话变成了 Unix 管道——一个 50 年后还在全世界亿级服务器上每秒运行几十亿次的设计。

Unix 的很多决定看起来”明显”，其实每一个都来自一个具体的历史语境。理解这些语境，是分辨”这是 Unix 的本质”和”这只是 Unix 的历史包袱”的唯一方法。 本文沿谱系走一遍，挑出留下的关键遗产：

哪些是”因为优秀所以幸存”（如管道）；
哪些是”因为先上车所以幸存”（如 fork）；
哪些是”本该幸存却被遗忘”（如 Plan 9 的命名空间，后来以容器形式回来了）；
哪些仍在悄悄演化（如 /proc 文本接口）。

在进入细节前，先看一张谱系图：

flowchart TB
    M[Multics 1965]
    M --> U[Unix V1 1971]
    U --> V6[Unix V6 1975]
    V6 --> V7[Unix V7 1979]
    V7 --> BSD[BSD 4.x]
    V7 --> SysV[System V]
    BSD --> FB[FreeBSD]
    BSD --> OB[OpenBSD]
    BSD --> NB[NetBSD]
    BSD --> Darwin[Darwin / XNU]
    Darwin --> macOS[macOS / iOS]
    V7 --> Plan9[Plan 9 1992]
    Plan9 --> Inferno[Inferno]
    Plan9 -.命名空间理念.-> Linux
    U -.克隆.-> Minix[Minix 1987]
    Minix -.灵感.-> Linux[Linux 1991]
    SysV -.POSIX.-> Linux
    NT[Windows NT 1993] -.独立谱系.-> NT
    L4[L4 / seL4] -.微内核.-> Fuchsia[Fuchsia / Zircon]
    classDef gone fill:#636e7b,color:#adbac7,stroke:#768390;
    classDef live fill:#388bfd,color:#cdd9e5,stroke:#388bfd;
    class M,Plan9,Inferno gone
    class Linux,FB,macOS,NT,Fuchsia live

灰色是已经退出主流或进入”博物馆”状态的系统；蓝色是仍在大规模生产使用的系统。虚线箭头是”思想影响”而非代码血缘——Linux 没有一行代码来自 Plan 9，但它的 namespace、/proc、9pfs 都是 Plan 9 的回声。

一、Multics：伟大的失败者

1965 年，MIT、Bell Labs 和 GE 联合启动 Multics（Multiplexed Information and Computing Service），目标：像”电力公司”那样把计算作为公共服务售卖。在 Multics 上工作的工程师里就有 Ken Thompson 和 Dennis Ritchie。

Multics 预置的设计极为超前：

分段 + 分页的两级虚拟内存（每段独立权限）
动态链接（第一个商业操作系统级的 dlopen 雏形）
分层访问控制（Ring，后来的 x86 ring 0/1/2/3 是 Multics 的回声）
可信计算基（TCB 概念的早期提出者之一）
PL/I 写成（高级语言写 OS，70 年代算激进）

它失败在哪里？规模失控。 1969 年 Bell Labs 撤出 Multics 项目，Thompson 和 Ritchie 决定写一个”Multics 的简化版”——这就是 Unix 的起点。Unix 的名字是 Peter Neumann 给起的，原本是 “UNICS”（Uniplexed），一个对 Multics 的玩笑。

Multics 留给 Unix 的核心遗产：

分层文件系统（hierarchical directory tree）
Shell 作为独立进程的概念
大量小工具组合的哲学雏形
Ring-based 保护（Intel 在 286/386 上实现时沿用 Multics 术语）

Multics 被 Unix 抛弃的东西：

分段内存（Unix 选了简单的线性地址 + 分页）
PL/I（Unix 后来用 C 重写）
复杂的访问控制（Unix 只保留 user/group/other × rwx）
动态链接（Unix 后来在 SunOS 4 才补上 ld.so，又过了十几年）

你可以把 Unix 看作是对 Multics 做了”简化 + 效率优化”的再发行版。今天读 Multics 的文档还在 multicians.org，它的很多理念在 90 年代才被 Windows NT 重新实现。

二、Unix V1–V7：哲学的凝结

2.1 V1（1971）：只做 PDP-7 的批处理

最早的 Unix 跑在 PDP-7 上，用汇编写成。它提供了极少的原语：fork、exec、read、write、open、close、creat（没错，少一个 e 是 Thompson 的打字笔误，然后被刻进 Unix 历史）。甚至没有管道。

2.2 V4（1973）：C 语言重写

Dennis Ritchie 设计了 C 语言，Thompson 和 Ritchie 把 Unix 从汇编重写成 C。这是 OS 历史上最重要的”自举”事件——一个 OS 如果用可移植的语言写成，就不再被绑定在一个硬件平台上。这让 Unix 后来移植到 VAX、Motorola 68000、SPARC、x86、ARM、riscv 变得可能。

2.3 V6（1975）：源码外发

V6 是第一个公开源码（对大学和研究机构收取 symbolic 授权费）的版本。John Lions 1977 年在澳大利亚新南威尔士大学写了《Lions’ Commentary on UNIX 6th Edition》——300 页的源码逐行注释，成为无数系统程序员的启蒙书。因为 AT&T 的法律介入，这本书地下流传了二十年，直到 1996 年才获准公开出版。

V6 内核大约 9000 行 C + 700 行汇编。今天 Linux 6.6 的 kernel/ 目录已是 60 万行。

2.4 V7（1979）：哲学定型

V7 是 Unix 设计定型的一版，诞生了：

stdio 标准库
Bourne shell（sh）
makefile 与 sccs
awk（Aho、Weinberger、Kernighan 的姓首）

更重要的是，Doug McIlroy 在《Unix Philosophy》的笔记里提出了那段著名的箴言：

Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

这三条在今天仍是 Unix 系工具的设计宪法。第三条”文本流”直接塑造了 /proc、/sys、日志、配置文件的全面文本化——也塑造了 JSON / YAML 取代二进制配置的趋势（虽然是在几十年后）。

2.5 V7 留下的核心遗产

fork/exec 拆分（进程创建与程序加载分离）
管道（pipe，pipe2 是 2008 年才加的 cloexec 版本）
文件描述符 0/1/2（stdin/stdout/stderr）
环境变量（envp）
可重定向的 I/O（shell < > |）
通配符与 glob（shell 里的 *.c 扩展由 shell 完成而非内核）
signal(2) 基础（但 V7 信号不可靠，reliable signals 到 SVR4 才定型）

fork/exec 拆分的真正价值：shell 可以在 fork 之后、exec 之前改变子进程的 fd、uid、cwd 等状态。你写的 ls > out.txt 能工作，是因为 shell 在 fork 之后 exec 之前把 fd 1 重定向到 out.txt。这种”中间状态可编程”的能力是 Windows 的 CreateProcess 无法轻易给出的——NT 的 CreateProcess 是原子的，要改环境就得用复杂的 STARTUPINFO 结构。

但 fork 在大内存进程里极贵（要复制整个页表，即使 COW）。现代 Linux 提供 posix_spawn 作为无 fork 的替代，但它在 glibc 里实际仍基于 clone + 立即 exec 实现（见 B-09）。

三、BSD：Unix 的学院派分叉

1977 年，伯克利的 Bill Joy 在 V6 上做了一批补丁，叫 1BSD。这启动了一条重要分叉。BSD 这条线贡献了：

vi 编辑器（1976–1977）
csh（C shell）
快速文件系统 FFS（1984，McKusick）——Unix 第一个真正严肃的文件系统设计
TCP/IP 实现（1983，4.2BSD）——几乎所有现代 OS 的 TCP/IP 代码都能追溯到 4.4BSD-Lite
virtual memory + mmap（4.4BSD 完成）
sockets API（sys/socket.h 的接口长什么样是 Berkeley 定的）
信号重构（sigaction 取代 signal，reliable signals）
jobs control（shell 的 fg/bg/&）
getopt（命令行解析）

4.4BSD（1994）是 BSD 的巅峰，但因 USL v. BSDi 诉讼（1992），4.4BSD-Lite 被迫删除了 AT&T 贡献代码。之后 BSD 一分为三：FreeBSD、NetBSD、OpenBSD，各走各路。

BSD 送给 Linux 的大礼：TCP/IP 栈的 API 和设计思路。Linux 内核最初的 socket 子系统基本对照 BSD 实现——这是为什么 POSIX socket API 在 Linux 和 BSD 之间高度兼容。

BSD 送给 macOS 的礼物：整个 userland。macOS 的 /bin、/usr/bin、libc、libsystem，主体是 FreeBSD 的派生。Darwin 的内核 XNU 则是 Mach + BSD kernel + Apple IOKit 的混合体（M-104 会展开）。

四、System V：商业化的 Unix

与 BSD 并行，AT&T 将 Unix 商业化为 System V（SVR1–SVR4）。SVR4（1989）是 AT&T 与 Sun 合作的成果，目标是统一 BSD 与 System V：

STREAMS（模块化 I/O 子系统，设计上优于 BSD mbuf，但 Linux 没采纳）
System V IPC（shmget/msgget/semget）——是 Linux 仍兼容但基本不推荐新用的 API
dynamic linking（ld.so）
FIFO（命名管道）
procfs（/proc 文件系统，Plan 9 借鉴后又反哺回 Linux）

Solaris（Sun 的 SVR4 衍生）后来贡献了两个现代 OS 的核心概念：

DTrace（2003）——动态追踪的开创性工具，直接影响了 Linux 的 ftrace / eBPF
ZFS（2005）——存储百科 17-zfs-integrity 细讲

商业 Unix 的黄昏：SCO、AIX、HP-UX、IRIX、Solaris 这些商业 Unix 在 2000 年后被 Linux 吃掉市场，只在少数 legacy 场景残留。但它们贡献的设计思想（特别是 Solaris 的很多机制）通过开源回到了 Linux 和 FreeBSD。

五、Plan 9：Unix 的”下一版”

Ken Thompson、Rob Pike、Dennis Ritchie 在 1980 年代末觉得 Unix 已经背上太多历史包袱，在 Bell Labs 启动了 Plan 9 from Bell Labs（名字致敬了 Ed Wood 的烂片）。

Plan 9 的核心野心是把”一切皆文件”推到极致：

5.1 所有资源通过 9P 协议暴露为文件

9P 是一个网络透明的文件协议。每个资源（进程、网络接口、窗口、CPU、甚至键盘鼠标输入）都用一个目录树表示，操作是 read/write/walk。这让”本地”和”远程”资源编程界面完全一致——你可以把另一台机器的 CPU mount 到本机 /mnt/cpu/，然后跑在上面。

5.2 每个进程自带 namespace

在 Plan 9 里，每个进程有自己独立的文件系统视图。父进程可以给子进程挂载不同的 /net、/proc、/env。容器时代的 mount namespace / pid namespace 是 Plan 9 namespace 的迟到二十年的回归。

5.3 UTF-8 的诞生

Rob Pike 和 Ken Thompson 在 Plan 9 的一间餐厅里发明了 UTF-8（1992 年 9 月 2 日晚，这事有精确时间戳）。这是 Plan 9 给世界的最大礼物——今天你看到的几乎每一份 HTTP 响应、JSON 文件、源代码都在用它。

5.4 为什么 Plan 9 失败？

Plan 9 几乎没有商业成功，原因粗略三条：

发布太晚（第一版 1992），Unix/Linux 的生态已经厚到无法动摇。
强制的”文件语义”对某些高性能场景不友好（虽然 9P 可以穿零拷贝）。
自带全套新工具链与新 C 方言，移植门槛高。

但它的思想几乎全部以隐秘方式回到主流 OS：Linux namespaces / unshare / setns 复刻了 Plan 9 的私有 namespace；/proc 和 /sys 的进一步扩展致敬了 9P 哲学；Go 语言（Pike 是主要设计者）在工具链哲学上继承 Plan 9（例如只有一种格式化 gofmt）。

六、Linux：意外的胜者

6.1 1991：那封著名的邮件

“Hello everybody out there using minix - I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.” — Linus Torvalds, 1991-08-25, comp.os.minix

Linus 原本的目标是 Minix 的可替代品，386 上的终端仿真器。它意外地成为了全球最广泛部署的内核，不是因为设计最优，而是：

选了宽松的 GPL v2 许可（1992）
选了宏内核而不是卷入微内核论战
选了 email + patch 的开发模型（没有公司所有权纠纷）
时机对——正好赶上互联网服务器爆发

6.2 Tanenbaum-Torvalds 论战

1992 年 Andrew Tanenbaum 在 comp.os.minix 发帖 “LINUX is obsolete”，批评 Linus 选宏内核。Linus 的回复辛辣直接。这场论战后来被印进操作系统教科书。

论战的核心矛盾：

Tanenbaum 认为微内核是”正确方向”（Mach 成熟、隔离性强）；
Linus 认为 “portability to different architectures is nice, but the fact that it works on one architecture isn’t really that important” —— 实用至上。

三十年后的结论：Linus 赢了部署量；Tanenbaum 赢了理论评分。seL4 证明了微内核可以做到形式化正确；Linux 证明了宏内核可以吃下所有商业场景。两者在不同问题空间各自正确。

6.3 Linux 继承了什么

Linux 是 BSD + SVR4 + Plan 9 + 自研的大杂烩：

ABI：几乎完全仿造 SVR4 + POSIX
TCP/IP：参考 BSD（但完全重写）
文件系统：VFS 抽象来自 SunOS / 早期 Linux 作者的原创
procfs：仿 Plan 9，字段布局受 SVR4 影响
namespaces：明确受 Plan 9 启发（2002 起逐步加入）
epoll：原创，解决 BSD kqueue 和 SVR4 /dev/poll 同样的问题但走了不同 API
cgroups / systemd：Google 发起 + Red Hat 推动，是 Linux 独有的
io_uring：原创，Jens Axboe 2019 年引入
eBPF：原创，源于 1992 年 BPF（BSD 包过滤器）的再生

6.4 Linux 的三类子系统

与 Unix 兼容层：signal、fork、fd、shell 工具链。这部分改动谨慎，Linus 的”never break userspace” 政策保底。
Linux 特色层：cgroup、namespace、eBPF、systemd、io_uring。这部分是 Linux 甩开其他 Unix 的原因。
硬件支持层：驱动、PM、ACPI。这部分是 Linux 最庞大、最难读、也最难贡献的部分，占内核代码的 > 60%。

七、Windows NT：平行宇宙

NT 不是 Unix 系，但和 Unix 有对话关系。NT 的主设计师 Dave Cutler 之前在 DEC 做 VMS，对 Unix 有清晰的”我偏要不一样”倾向：

维度	Unix	NT
进程创建	fork + exec	CreateProcess（原子）
文件描述符	小整数	HANDLE（不透明指针）
异步 I/O	AIO / io_uring	IOCP（第一天就有）
类型系统	弱（ioctl 号）	Object Manager + Handle Type
用户接口	POSIX-ish	Win32 + NT syscall + kernel objects
时钟	gettimeofday + monotonic	QueryPerformanceCounter
注册表	无（文本文件散落）	中心化 Registry
守护进程	进程 + init	Service Control Manager

NT 的一些设计，例如 IOCP、早期的 async I/O、对象管理器，在 Linux 里分别对应 io_uring、kernel 对象（fd、pidfd、file）。M-104 会详细比较 NT 与 Linux 的内部架构差异。

Windows 的 WSL2（2019）直接把 Linux 内核跑在 Hyper-V 的 VM 里，Microsoft 接受了”Linux 赢了服务器”的事实。这是近三十年 OS 格局最大的信号。

八、macOS / iOS：XNU 的混血

macOS 的内核 XNU 是：

Mach（IPC、调度、虚存）
BSD layer（POSIX API、文件系统、网络栈）
IOKit（C++ 驱动框架）

三者在同一地址空间共处。它的 BSD userland 来自 FreeBSD 衍生，但内核架构深受 NeXTSTEP（Mach 3.0 + 4.3BSD）影响，因为 Apple 在 1997 年收购 NeXT 后把 NeXTSTEP 变成了 Mac OS X。

XNU 贡献给开源的东西不多（Apple 在 Darwin 项目下开源了内核主干，但外围的 Metal、WindowServer、Cocoa 都是私有）。但 XNU 的 Mach 部分启发了 Linux 的 bpf、dtrace 移植工作。

九、其他重要分支

9.1 AIX / HP-UX / IRIX / Solaris

商业 Unix，各有贡献但都已边缘：

AIX：JFS（日志文件系统先驱之一）、LPAR（硬件级分区）
HP-UX：最严格的 POSIX 实现之一
IRIX：XFS（现在在 Linux 主线）、OpenGL 生态
Solaris：DTrace、ZFS、Zones（容器先驱）、SMF、kstat

9.2 BeOS / Haiku

BeOS（1991–2001）以响应性著称；Haiku 是其开源重生。多线程模型激进（每个 GUI 元素自带线程），对 Unix 有强烈对立哲学。虽未成主流，但它证明了 OS 设计不必只走 Unix 一条路。

9.3 QNX / VxWorks / Zephyr

实时 OS。QNX 是微内核教科书（M-105 详述）；VxWorks 统治航空电子；Zephyr 在 IoT 设备上崛起。它们不是”Unix-like”，但都提供了 POSIX 兼容子集。

9.4 Android

Android 的内核是 Linux，但 userland 不是 Unix：

Bionic libc（不是 glibc，更小，针对移动优化）
Binder IPC（不是 SysV / POSIX IPC，自研对象引用传递）
ART / Dalvik runtime（应用跑在托管运行时，不直接操作 POSIX）
Zygote 进程（预热应用模板，避免每次 fork + exec 的成本）

Android 把 Linux 内核当 substrate 用，但几乎抛弃了 Unix 的用户空间传统。这是一个值得研究的分叉——它证明了 Linux 内核可以驱动一个”非 Unix”用户空间，为 unikernel / 新用户空间的探索提供了参考。

9.5 ChromeOS / Fuchsia

ChromeOS：Linux 内核 + Chrome 浏览器作为唯一用户接口。把 OS 抽象进一步压薄。

Fuchsia：Google 的全新微内核 OS（Zircon 内核，非 Unix 血统）。从 2016 年启动，2021 年首次在 Nest Hub 上商用。Fuchsia 的哲学更接近 Plan 9 + 能力模型：所有 IPC 走 handle + capability，彻底抛弃 POSIX。它是否能突破”微内核不流行”的历史魔咒还待观察。

十、设计遗产清单

把上面所有讨论浓缩成一张”哪些活着、哪些死了”的清单：

10.1 活下来的

fork/exec（B-09 展开其争议）
文件描述符（即使在 io_uring、NT 里也有对等物）
“一切皆文件”（/proc、/sys、bpf fd、eventfd、pidfd）
shell + 管道 + 文本流（UTF-8 流）
Makefile 风格的增量构建（直到 Bazel/ninja 也在保留其精神）
分层文件系统（虽然不是所有 OS 都有，但事实标准）
signal（尽管骂声不断）
user/group/other × rwx（即使 ACL 盛行，这仍是底线）

10.2 死掉或边缘化的

STREAMS（Linux 从未采纳）
mbuf（BSD 内部仍用，但 Linux 用 sk_buff 取代）
硬连接跨设备（POSIX 禁止）
setuid 二进制（逐步被 capabilities 取代）
SysV IPC（被 POSIX IPC、eventfd、shared memory 替代）
RPC over ONC（被 gRPC/HTTP2 替代）
X11（被 Wayland 取代，Plan 9 的 8½/rio 思路迟到的胜利）

10.3 借尸还魂的

Plan 9 的 namespace → Linux namespaces → 容器
Plan 9 的 9P → virtio-9P → virtio-fs（虚机与 host 文件共享）
Solaris DTrace → Linux ftrace + eBPF
Solaris Zones → Linux containers
Apollo 的 tokens → Linux capabilities

10.4 反复尝试中的

微内核（Mach → L4 → seL4 → Fuchsia）
Unikernel（Nemesis → MirageOS → Unikraft）
Capability OS（KeyKOS → EROS → CapROS → seL4 / Fuchsia）

十一、这些历史为什么对你重要？

读历史不是怀旧。每一个”看起来奇怪”的 Unix / Linux 设计，背后都有一个具体时代的约束：

为什么 fork 采用 COW 而不是显式传递起始状态？因为 1970 年 PDP-11 内存只有 64KB，COW 比重新分配更省内存。
为什么 signal 那么拧巴？因为 V7 只打算用它做”kill 一个进程”，后来需求一直叠加，重构成本又太高。
为什么 /proc 是文本不是结构化二进制？因为 Plan 9 的”文本即 UI”哲学，加上 Linux 早期对 shell 脚本的偏爱。
为什么 cgroup v1 层级混乱？因为它是 Google 先在内部用、外包给社区后不同 controller 独立演化的结果。
为什么 io_uring 是 2019 才出现？因为 POSIX AIO / libaio 在二十年里反复尝试都不好用，直到 Jens Axboe 重新设计。

把当下的工程决定放到历史语境里看，你就能区分”这是本质”和”这是惯性”。当某个时代条件改变时（比如内存白菜价了、容器化常态了、机密计算普及了），就是”打破惯性、重新设计”的窗口。

本系列后面很多章节会不断回到这个视角。比如：

B-09 会重新讨论 fork 是否该被 posix_spawn 取代；
B-13 会讨论信号能否被 eventfd / io_uring event 完全替代；
G-57 会讨论 io_uring 是否会逐步吃掉 read/write 的热路径；
L-95 会讨论 capabilities 是否该彻底取代 setuid；
M-107 会讨论 Rust for Linux 如何重新划分安全边界。

每一次讨论背后都是”惯性 vs 当下约束”的权衡。

十二、小结

Unix 从 Multics 的简化版出发，经 V7 哲学定型，通过 BSD 与 SVR4 两条线分别服务于学术和商业。Plan 9 是它的”下一版”但没能取胜，思想通过 namespace、UTF-8、Go 语言进入主流。Linux 是宏内核 + BSD API + Plan 9 点子 + 自研特性的大杂烩，在 1990s 后半期起接管了服务器市场。NT 是平行宇宙；XNU 是混血；Android 把 Linux 内核嫁接到非 Unix userland 上。

这是我们即将开始的内核深挖之旅的历史底图。下一篇我们进入 A-03 宏内核 vs 微内核——把 Tanenbaum-Torvalds 论战的三十年后结论讲清楚。

参考文献

历史档案

multicians.org —— Multics 官方历史与文档
www.tuhs.org（The Unix Heritage Society）—— 收藏了 V1–V7 全部源码、Research Unix 的邮件档案
Plan 9 手册：https://9p.io/wiki/plan9/plan_9_wiki
“Lions’ Commentary on UNIX 6th Edition, with Source Code”（最终合法出版 1996）

论文

Ritchie, D. M., Thompson, K. “The UNIX Time-Sharing System.” CACM, 17(7):365-375, 1974.
Pike, R., Presotto, D., Dorward, S., Flandrena, B., Thompson, K., Trickey, H., Winterbottom, P. “Plan 9 from Bell Labs.” Computing Systems, 8(3):221-254, 1995.
Pike, R. “The Use of Name Spaces in Plan 9.” ACM SIGOPS OSR, 27(2):72-76, 1993.
Cutler, D. N., Probert, D. B. “A Marketing Perspective of Windows NT.” 1993 internal memo (published later).
Accetta, M., et al. “Mach: A New Kernel Foundation for UNIX Development.” USENIX Summer, 1986.

邮件与论战

Tanenbaum-Torvalds debate, 1992, comp.os.minix. 完整存档：http://www.oreilly.com/openbook/opensources/book/appa.html
Linus Torvalds 最初公告：https://groups.google.com/g/comp.os.minix/c/dlNtH7RRrGA/m/SwRavCzVE7gJ

书籍

Salus, P. H. A Quarter Century of UNIX. Addison-Wesley, 1994.
Kernighan, B. W. UNIX: A History and a Memoir. 2019.（贝尔实验室当事人口述）
Russinovich, M. E., Solomon, D. A., Ionescu, A. Windows Internals. 7th Edition, Microsoft Press, 2017.
Singh, A. Mac OS X Internals: A Systems Approach. Addison-Wesley, 2006.

源码考古

V6 Unix：https://github.com/memononen/unix-v6
V7 Unix：https://github.com/dspinellis/unix-history-repo
4.4BSD-Lite：https://github.com/sergev/4.4BSD-Lite2

上一篇：什么是操作系统 下一篇：宏内核 vs 微内核

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2026-04-17 · os

【操作系统百科】系统调用 ABI：x86_64 / arm64 / riscv / Windows NT 对照

系统调用是 OS 最稳定的接口。本文拆解 Linux syscall 的参数寄存器约定、返回值规范（负 errno 与 2-value ABI）、x86_64 SYSCALL、arm64 SVC、RISC-V ECALL、Windows NT 的 int 2e/syscall/SYSENTER 历史；说明为什么 Linux 承诺 \"don't break userspace\"、什么东西算 syscall ABI、vDSO 如何用共享内存加速、Go/musl/glibc 各自怎么实现 syscall stub。