从这一篇开始进入第二部分：深入层。前 17 篇回答「怎么用」，接下来 23 篇回答「为什么被设计成这样」。

第一篇不讲具体机制，而是建立一个分析框架：任何设计都是在特定约束下的权衡，理解约束才能理解设计。 这个框架会贯穿后面所有篇目。

先看五个问题：

1. 「一切皆文件」到底给了什么好处、又付出了什么代价？
2. 为什么 Linux 选了宏内核？微内核在理论上更优雅，为什么输了？
3. POSIX 是谁和谁的妥协？为什么它既救了 Unix 又限制了它？
4. 为什么 Linux 的系统调用几十年不变，而内核内部接口可以随意改？
5. 为什么 Unix 工具都这么「简陋」（grep 只过滤、sed 只替换）？这是优点还是历史局限？

1. 先理解约束：1969 年的现实

任何「设计哲学」都不是凭空产生的审美选择，而是约束下的生存策略。 Unix 的约束极其严苛：

1969 年，贝尔实验室，Ken Thompson 手上的机器：

  PDP-7
    内存：8K 字（18 位字长，约合 18KB）
    存储：磁鼓，没有硬盘
    显示：电传打字机（Teletype），每秒 10 个字符
    用户：一个人

对比一下：
  这台机器的内存，装不下现在一张缩略图。
  它的「屏幕」是一台打字机，输出一屏文字要 10 秒以上。

1.1 Multics 的教训

Unix 的直接动因是 Multics 项目的失败。Multics（1964 起）由 MIT、通用电气、贝尔实验室联合开发，目标极其宏大：

Multics 想做的事：
  ✓ 分时多用户
  ✓ 动态链接（运行时加载模块）
  ✓ 单级存储（内存和文件统一寻址）
  ✓ 细粒度访问控制（ACL、环保护）
  ✓ 高可用（可在线更换硬件）
  ✓ 用高级语言（PL/I）编写

结果：
  ✗ 1969 年，5 年过去仍未可用
  ✗ 代码量与复杂度失控
  ✗ 贝尔实验室退出项目

Ken Thompson 和 Dennis Ritchie 的反应不是「做得更好」，而是「做得更小」。 Unix 这个名字本身就是对 Multics 的戏仿（MULTICS 的 “multi” → UNICS 的 “uni”）。

所以 Unix 的「简单」首先是一种生存策略：在 8KB 内存的机器上，你没有任何余地做优雅的抽象层，每一个字节都要算。「小而专一的工具」不是美学偏好，而是唯一可行的方案。

1.2 用 C 重写：可移植性的诞生

1973 年发生了 Unix 历史上最重要的转折：Thompson 和 Ritchie 用 C 重写了整个内核。

在此之前，操作系统一律用汇编写，换一台机器就要从头重写。C 语言的出现让 Unix 成为第一个可移植的操作系统。

这个决定的后果链：

  用 C 写内核
       ↓
  Unix 能移植到任何有 C 编译器的机器
       ↓
  大学用它做教学（AT&T 以极低价格授权给高校）
       ↓
  一代程序员在 Unix 上长大
       ↓
  他们进入工业界，带来 Unix 的思维方式
       ↓
  BSD、Minix、Linux、macOS 都源自这条脉络

代价也很明确：C 语言把内存管理完全交给程序员，这是后来五十年里绝大多数安全漏洞的根源（缓冲区溢出、UAF、整数溢出）。Linux 内核在 2022 年开始引入 Rust，正是对这个代价的迟来回应。

2. 一切皆文件：最著名的抽象

2.1 它的真实含义

「一切皆文件」经常被误解成「所有东西都是磁盘上的文件」。它真正的含义是：所有 I/O 资源都用同一组系统调用来操作。

// 这五个系统调用适用于：普通文件、目录、管道、socket、终端、
//                      块设备、字符设备、/proc 里的内核数据、eventfd、
//                      timerfd、signalfd、epoll 实例、内存文件（memfd）……
int  open(const char *path, int flags, ...);
ssize_t read(int fd, void *buf, size_t count);
ssize_t write(int fd, const void *buf, size_t count);
int  close(int fd);
int  ioctl(int fd, unsigned long request, ...);

# 同一个工具能操作完全不同的东西 —— 这就是收益
cat /etc/passwd                      # 普通文件
cat /proc/cpuinfo                    # 内核数据（不存在于磁盘）
cat /sys/class/net/eth0/mtu          # 设备属性
cat /dev/urandom | head -c 16         # 字符设备
cat < /dev/tcp/example.com/80         # 网络连接（bash 的特性）
cat namedpipe                         # 命名管道
cat /proc/self/fd/0                   # 自己的标准输入

# 反过来，写入也一样
echo 1 > /proc/sys/net/ipv4/ip_forward       # 改内核参数
echo mem > /sys/power/state                  # 让机器睡眠
echo 1400 > /sys/class/net/eth0/mtu          # 改网卡 MTU

这个抽象的三层收益：

1. 工具可组合 —— grep、awk、tee 不需要知道数据来自文件还是网络，它们只操作 fd
2. 权限模型统一 —— 设备访问控制复用了文件权限（ls -l /dev/sda 的 brw-rw---- 就是权限位）
3. 可脚本化 —— 能用 shell 配置硬件、读内核状态，不需要专门的 API 和工具

2.2 代价一：不是所有东西都像文件

最著名的破例是 socket。 如果「一切皆文件」彻底成立，网络连接应该是这样的：

# 假想的、彻底的「一切皆文件」（Plan 9 就是这么做的）
fd=$(open /net/tcp/example.com/80)
write $fd "GET / HTTP/1.0\r\n\r\n"
read $fd

但真实的 Linux socket API 是这样：

int sockfd = socket(AF_INET, SOCK_STREAM, 0);       // ← 不是 open()
connect(sockfd, (struct sockaddr*)&addr, sizeof(addr));  // ← 全新的调用
bind(sockfd, ...); listen(sockfd, 128); accept(sockfd, ...);
setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, ...);  // ← 又一套配置机制
// 之后才能用 read/write（也可以用 send/recv）

为什么 socket 挤不进这个抽象？ 三个根本原因：

① 没有路径名可用
   文件的 open() 需要一个路径，而「TCP 连接」这个概念里没有自然的路径。
   要造一个（如 /net/tcp/host/port），就得设计一整套命名空间。

② 建立连接是有状态的多步过程
   open() 是一次性的原子操作，而 TCP 需要 socket -> bind -> listen -> accept
   或 socket -> connect 这样的状态机。用 open() 表达不了。

③ 配置项的维度爆炸
   TCP 有几十个可调项（nodelay、keepalive、缓冲区、拥塞算法……），
   而文件抽象里没有地方放这些 —— 于是有了 setsockopt。

Plan 9（贝尔实验室在 Unix 之后做的实验性系统，同一批人）把这件事做到了彻底：网络、进程、图形界面全部是文件系统里的路径。它证明了这条路技术上可行，但没有普及 —— 因为 Unix/POSIX 的 socket API 已经是既成事实，生态惯性远大于设计优雅性。

这是本篇最重要的一课：设计的胜出与「是否优雅」关系不大，与「是否已经形成生态」关系极大。 后面讲 systemd（37 篇）、讲 epoll vs io_uring（30/32 篇）时会反复看到这条规律。

2.3 代价二：ioctl 成了垃圾桶

read/write 只能表达「传输一串字节」。但设备操作远不止于此：磁盘要能查询容量、终端要能设置回显、网卡要能改 MTU —— 这些操作在「读写字节流」的抽象里无处安放。

于是有了 ioctl（I/O control）：

int ioctl(int fd, unsigned long request, ...);
//                ^^^^^^^^^^^^^^^^^^^^^ 一个数字，代表「你想干什么」
//                                  ^^^ 可变参数：可能是整数，可能是任意结构体指针

它是一个逃生舱：所有无法用 read/write 表达的操作，全都塞进这里。 代价是：

✗ 完全没有类型安全 —— 第三个参数是 void*，传错结构体就是内存越界
✗ 请求码是平坦的数字空间，各驱动自行定义，冲突和混乱不可避免
✗ 无法自我描述 —— 你不能「问」一个 fd 支持哪些 ioctl
✗ 不可移植 —— 同一个 ioctl 号在不同架构/内核版本上可能含义不同
✗ 成了安全漏洞高发区 —— 内核 CVE 里 ioctl 相关的占相当比例

# 看看 ioctl 承担了多少种职责
grep -c 'define.*_IO' /usr/include/linux/*.h | sort -t: -k2 -rn | head -5
# 数千个 ioctl 定义，涵盖：终端、磁盘、网络、KVM、DRM、USB、V4L2……

# 这些命令的背后全是 ioctl
stty -a                    # 终端设置（TCGETS/TCSETS）
blockdev --getsize64 /dev/sda   # 磁盘容量（BLKGETSIZE64）
ip link set eth0 mtu 1400  # 网卡 MTU（SIOCSIFMTU；现代改走 netlink）
losetup -f disk.img        # 回环设备（LOOP_SET_FD）

# 用 strace 观察
strace -e trace=ioctl stty -a 2>&1 | head -3
# ioctl(0, TCGETS, {c_iflag=..., c_oflag=...}) = 0
# ioctl(0, TIOCGWINSZ, {ws_row=24, ws_col=80}) = 0

内核后来的补救：新的子系统改用结构化的替代方案而不是继续加 ioctl：

2.4 代价三：语义泄漏

「统一接口」承诺所有 fd 行为一致，但实际上不一致。这些差异会泄漏到应用代码里：

// read() 在不同 fd 类型上的行为差异
ssize_t n = read(fd, buf, 4096);

// 普通文件：几乎总是读满 4096（除了文件末尾），可以 lseek
// 管道：    可能只返回几个字节（写端只写了那么多），不能 lseek
// socket：  可能返回任意小的正数（TCP 是字节流，不保证消息边界）
// 终端：    行缓冲模式下，回车才返回
// /proc：   一次读取生成全部内容，第二次读返回 0（有些文件不支持部分读）

这解释了几个实际的坑（前面篇目遇到过）：

# ① 为什么 wc -c < file 很快，cat file | wc -c 很慢（09 篇 3.4）
#    因为普通文件能 lseek 到末尾直接拿大小，管道不能
wc -c < bigfile        # 瞬间
cat bigfile | wc -c    # 要读完全部数据

# ② 为什么 Go 的 Write 可能部分写入（06 篇的 man 2 write）
#    "it is not an error if this number is smaller than requested"

# ③ 为什么 tail -f 对管道无效
#    管道没有「文件末尾」的概念，也无法 seek 回去

// 所以正确的读写必须处理部分传输 —— 这是「统一抽象」的语义泄漏
// ❌ 错误假设：以为一次 Read 能拿到完整消息
n, _ := conn.Read(buf)
processMessage(buf[:n])         // TCP 是字节流，可能只收到半条消息

// ✅ 必须自己做消息边界
io.ReadFull(conn, header)                    // 读满固定长度的头
io.ReadFull(conn, body[:length])             // 按头里的长度读满
// 或者用 bufio.Scanner + 自定义 SplitFunc

2.5 代价四：性能

「一切皆文件」意味着每次 I/O 都要经过 fd 查找、权限检查、VFS 分派（20 篇细讲）。在极高性能场景下这个开销变得显著：

一次 read() 的路径：
  用户态 → 系统调用（陷入内核，上下文切换开销）
        → 查 fd 表，拿到 struct file
        → 调用 file->f_op->read_iter（VFS 分派，间接调用）
        → 具体文件系统/驱动的实现
        → 拷贝数据到用户缓冲区
        → 返回用户态

在每秒百万次 I/O 的场景下，仅「陷入内核」的开销就占了相当比例。
（Spectre/Meltdown 的缓解措施让这个开销更大了）

这就是 io_uring 被发明的动机（32 篇细讲）：用共享内存的环形队列批量提交请求，一次系统调用处理成百上千个 I/O，绕开「每次 I/O 一次陷入」的模型。DPDK、SPDK 走得更远 —— 完全绕过内核，在用户态直接操作网卡和 SSD。

注意这不是否定「一切皆文件」，而是它的边界：这个抽象在通用性上的价值极大，但在极致性能场景下需要旁路。好的工程判断是知道边界在哪。

3. 组合优于集成：管道与小工具

3.1 管道的发明

1973 年，Doug McIlroy 提出管道的构想，Ken Thompson 用一晚实现。McIlroy 后来总结的这段话是 Unix 哲学最常被引用的表述：

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.

为什么工具必须「简陋」？ 因为可组合性要求接口窄。

# grep 只做一件事：过滤行。所以它能出现在任何管道的任何位置
cat access.log | grep 500 | awk '{print $1}' | sort | uniq -c | sort -rn | head
journalctl -u myapp | grep ERROR | tail -50
ps aux | grep nginx | awk '{print $2}' | xargs kill

# 如果 grep 「功能更强」—— 比如内置排序、统计、格式化输出 ——
# 它就会与其他工具的职责重叠，组合时产生歧义，
# 而且它的输出格式会变复杂，下游更难解析。

这是一个深刻的工程原则：功能强大的组件难以组合，因为它们对上下文有更多假设。窄接口的组件反而能构造出无穷的组合。

3.2 文本作为通用接口：收益与代价

选择「文本行」作为工具间的通用格式，是 Unix 最有争议的决定之一。

收益：

# ① 人类可读 —— 每一步都能肉眼检查（这是调试能力的巨大优势）
ps aux | grep nginx        # 中间结果直接能看懂

# ② 任何语言都能生产和消费 —— 不需要共享库、不需要 IDL、不需要序列化框架
# ③ 可以手工构造测试输入
echo "fake log line" | ./myfilter
# ④ 持久化与传输免费（文本可以直接存文件、发邮件、贴到工单里）

代价：

# ① 解析脆弱 —— 输出格式变化会破坏下游（08 篇的 ls 输出不可解析）
ls -l | awk '{print $9}'   # ❌ 文件名带空格就错；ls 版本不同列也可能变
# ② 无类型 —— 一切都是字符串，数值比较、日期处理都要额外转换
# ③ 信息丢失 —— 结构化数据被压平成文本，嵌套关系表达不了
docker ps | awk ...        # ❌ 容器的标签、挂载点这些嵌套信息压不进表格
# ④ 性能 —— 序列化/反序列化的开销，以及大量 fork（17 篇 10.1）

3.3 对比：PowerShell 的对象管道

微软在 2006 年做了一个明确的反向选择：PowerShell 的管道传递对象而不是文本。

# PowerShell：管道里流动的是 .NET 对象，有类型、有属性
Get-Process | Where-Object {$_.CPU -gt 100} | Select-Object Name, CPU | Sort-Object CPU -Descending
#                          ^^^^^^^^^^^^^^ 直接访问属性，不需要解析文本

# Unix：必须解析文本
ps aux | awk '$3 > 10 {print $11, $3}' | sort -k2 -rn
#             ^^^^^^^ 靠列号定位，脆弱（列位置变了就错）

两者的取舍很清晰：PowerShell 更可靠但耦合到一个运行时；Unix 更脆弱但任何东西都能参与（一个十行的 Python 脚本、一个 C 程序、一个 curl 调用，都能无缝插进管道）。

3.4 今天的边界：结构化数据的回归

Unix 哲学在结构化数据上确实力不从心，而现代运维的数据大量是结构化的（JSON API、K8s 资源、云厂商元数据）。业界的答案不是抛弃管道，而是把 JSON 作为新的通用接口：

# ✅ 现代 Unix 风格：管道里流动 JSON，用 jq 做「结构化的 awk」
kubectl get pods -o json | jq -r '.items[] | select(.status.phase!="Running") | .metadata.name'
docker inspect x | jq -r '.[0].NetworkSettings.IPAddress'
aws ec2 describe-instances | jq -r '.Reservations[].Instances[] | [.InstanceId, .State.Name] | @tsv'
journalctl -o json | jq 'select(.PRIORITY <= "3")'
ip -j addr | jq -r '.[] | select(.operstate=="UP") | .ifname'
#  ^^ 连 iproute2 都加了 -j（JSON 输出）

# 工具生态也在跟上
# jq（JSON）、yq（YAML）、mlr（CSV/JSON）、dasel（多格式）、fx（交互式）
# 很多现代 CLI 默认提供 --json / -o json

这恰恰印证了 Unix 哲学的核心不是「文本」，而是「通用接口 + 小工具组合」。 接口从纯文本演进成 JSON，哲学本身没变。

4. 机制与策略分离

这是 Unix/Linux 最重要但最少被提及的原则：内核提供机制（mechanism），用户态决定策略（policy）。

机制 = 「能做什么」的能力，尽量通用、无偏见
策略 = 「应该怎么做」的决定，属于具体场景

例子一：epoll 只提供事件通知，不规定并发模型

// 内核给的机制：告诉你哪些 fd 就绪了
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

// 用户态自由决定策略：
//   - 单线程事件循环（nginx、redis）
//   - 线程池 + 每线程一个 epoll（Go runtime 的 netpoller）
//   - 一个 epoll + 多线程竞争 accept（EPOLLEXCLUSIVE）
//   - 协程调度（Go、Rust async）
// 内核对此完全不关心，也没有偏好

例子二：cgroup 只提供资源限制，不规定资源策略

# 内核机制：这个 cgroup 最多用 2 核、2GB 内存
echo "200000 100000" > /sys/fs/cgroup/myapp/cpu.max
echo "2G" > /sys/fs/cgroup/myapp/memory.max

# 策略完全在用户态：
#   systemd 决定「服务的默认配额」
#   Docker 决定「容器的资源模型」
#   K8s 决定「requests/limits、QoS 分级、驱逐顺序」
# 内核只管执行，不管这些概念

例子三：调度器提供权重，不定义「重要性」

# 内核机制：nice 值和 cgroup 权重决定 CPU 份额
nice -n 10 ./batch
echo 200 > /sys/fs/cgroup/myapp/cpu.weight

# 「哪个业务更重要」是策略，内核不知道也不该知道

这个原则的价值：机制稳定，策略可以随时演进。epoll 的接口十几年没变，但基于它的并发模型从「每连接一线程」演进到了协程；cgroup 的接口稳定，但容器编排从 Docker 演进到了 K8s。

这也是 systemd 争议的核心之一（37 篇细讲）：批评者认为它把大量策略（日志格式、启动逻辑、DNS 解析、时间同步）打包进了基础层，破坏了「机制与策略分离」，让用户失去了替换的自由。支持者则认为，某些策略的统一本身就是价值（不用每个发行版重新发明一遍）。

5. 宏内核 vs 微内核

5.1 两种架构

   宏内核（Monolithic）                    微内核（Microkernel）
   +----------------------------+          +------------------------+
   |  用户程序                   |          |  用户程序               |
   +----------------------------+          +------------------------+
   |  ↕ 系统调用                 |          | 文件系统 | 驱动 | 网络栈 |  ← 都在用户态
   +============================+          +------------------------+
   |  内核（一个地址空间）        |          |  ↕ IPC 消息传递          |
   |  ┌──────┬──────┬────────┐  |          +========================+
   |  │调度器│内存  │文件系统 │  |          |  微内核（只有最小功能）  |
   |  ├──────┼──────┼────────┤  |          |  IPC + 调度 + 地址空间   |
   |  │网络栈│驱动  │IPC      │  |          +------------------------+
   |  └──────┴──────┴────────┘  |
   +----------------------------+

   优势：组件间是【函数调用】       优势：故障隔离（驱动崩溃不影响内核）
        没有 IPC 开销                    最小可信基（TCB 小，便于形式验证）
   劣势：一个 bug 可能拖垮整个系统   劣势：每次跨组件都要 IPC（上下文切换 + 拷贝）
        代码庞大，耦合风险高              开发和调试复杂度高

5.2 Tanenbaum-Torvalds 辩论（1992）

Linux 发布一年后，Minix 作者、《现代操作系统》作者 Andrew Tanenbaum 在 comp.os.minix 上发了一篇著名的帖子，标题是「LINUX is obsolete」（Linux 已经过时）：

Tanenbaum 的论点：
  1. 宏内核在 1990 年代已经是过时的设计，微内核才是未来
  2. Linux 与 x86 绑定太紧，不可移植
  3. 单人开发的免费系统不会有前途

Torvalds 的回应（要点）：
  1. 微内核理论优雅，但 IPC 开销真实存在，且工程复杂度被低估了
  2. 可移植性可以后来解决（后来 Linux 移植到了几十种架构，反而是最可移植的内核）
  3. 「你的工作是教学，我的工作是做一个能用的系统」

5.3 微内核为什么输了（在通用领域）

三十年后回看，结论不是「微内核错了」，而是「微内核的收益在通用场景下不足以抵消成本」：

微内核在专用领域赢了：seL4（形式验证过的微内核）用在航空、军事、汽车；QNX 用在车载系统；Google Fuchsia 的 Zircon 也是微内核架构。这些场景里「可验证的安全性」比性能更重要 —— 印证了「设计优劣取决于约束」这个框架。

5.4 Linux 的实际形态：可扩展的宏内核

# Linux 不是「纯粹的」宏内核，它有一整套扩展机制
lsmod | head                       # 动态加载的内核模块（不用重编译内核）
sudo modprobe overlay              # 按需加载
ls /lib/modules/$(uname -r)/kernel/    # 模块目录

# fuse：文件系统跑在用户态（微内核思想的局部应用）
ls /dev/fuse
# sshfs、s3fs、rclone mount、gocryptfs 都基于它

# eBPF：把（受验证器保护的）代码注入内核（38 篇细讲）
sudo bpftool prog list
# 它让内核可编程，同时保证安全 —— 这是「宏内核 + 安全扩展」的现代答案

# 用户态驱动：DPDK/SPDK 完全绕过内核网络/存储栈

所以准确的描述是：Linux 是一个宏内核，但通过模块化、FUSE、eBPF 和用户态旁路，在需要的地方获得了微内核的部分好处。这是典型的工程务实主义 —— 不追求架构纯粹性，只解决实际问题。

6. 稳定的 ABI 与不稳定的内核内部

6.1 「我们不破坏用户态」

这是 Linux 最强的承诺，也是它与几乎所有其他开源项目的最大区别。Torvalds 的原话（措辞已简化）：

We do not break userspace. 内核的唯一职责是服务于用户态程序。如果一次内核升级让原来能跑的程序跑不了了，那就是内核的 bug，不管那个程序写得多糟糕。

# 实际后果：1995 年编译的二进制，在 2026 年的内核上依然能运行
# 系统调用一旦发布，它的编号、参数、语义【永不改变】
grep -n 'write' /usr/include/asm/unistd_64.h | head -3
# #define __NR_write 1                   <- 这个 1 永远是 write，不会变

# 需要新语义时，只能【新增】系统调用，而不是修改旧的
# 于是有了一串"家族"：
ls /usr/include/asm-generic/unistd.h >/dev/null
# open      -> openat      -> openat2         （逐步增加参数与标志）
# dup       -> dup2        -> dup3
# pipe      -> pipe2
# epoll_wait -> epoll_pwait -> epoll_pwait2
# clone     -> clone3
# wait4     -> waitid
# 每一代都保留，因为老程序还在用

6.2 对比：内核内部接口毫无保证

# 内核明确声明：内部 API 随时可能改变
ls /usr/src/linux/Documentation/process/stable-api-nonsense.rst 2>/dev/null
# 文档标题就叫 "The Linux Kernel Driver Interface (all your questions
#              answered and then some)" —— 副标题是 "stable API nonsense"

内核的立场是：内部接口稳定性是有害的，因为它会锁死重构能力。想要长期可用，就把驱动合并进主线，这样内核开发者重构时会顺手改你的代码。

这与 Windows 的选择正好相反：Windows 长期保持驱动 ABI 稳定，让厂商可以发布二进制驱动（不开源）。代价是内核难以重构，并且要为兼容性付出巨大复杂度。

# 这个策略差异的实际影响
# Linux：NVIDIA 闭源驱动每次内核升级都可能要重新编译（DKMS 就是为此而生）
dkms status
# 而进了主线的驱动（如 Intel 显卡、绝大多数网卡）永远开箱可用

# Linux 提供的用户态 ABI 稳定性验证工具
sudo abidiff /path/old.so /path/new.so   # 用户态库的 ABI 对比（libabigail）

6.3 这个选择对 Go 服务的实际意义

// Go 直接发系统调用（不依赖 libc，01 篇讲过静态编译）
// 因为系统调用 ABI 永不改变，所以：
//   ✅ 一个静态编译的 Go 二进制能在任何较新内核上运行（甚至 scratch 镜像）
//   ✅ 不用担心「内核升级导致程序跑不了」
//   ⚠️ 但【新】特性需要检测：内核太老时对应的系统调用不存在

// 典型的特性探测模式
fd, err := unix.Openat2(...)                       // 内核 5.6+
if errors.Is(err, unix.ENOSYS) {                   // 系统调用不存在
    fd, err = unix.Openat(...)                     // 回退到老接口
}
// Go runtime 自己就大量使用这种模式：
//   epoll_pwait2（5.11+）不可用时回退 epoll_pwait
//   如果检测不到 io_uring 支持就用 epoll

7. POSIX：标准化的妥协

7.1 Unix 战争

1980 年代，Unix 分裂成两大阵营，互不兼容：

   AT&T System V                        BSD（加州大学伯克利分校）
   ├─ 商业授权                          ├─ 学术自由传播
   ├─ 引入 STREAMS、SysV IPC             ├─ 引入 socket、vi、csh、TCP/IP 实现
   └─ 衍生：HP-UX、AIX、Solaris          └─ 衍生：SunOS、FreeBSD、NetBSD、macOS

   同一件事的两套 API：
     进程状态：  ps -ef        vs  ps aux            （13 篇讲过它们并存至今）
     IPC：       SysV IPC      vs  socket / mmap
     终端控制：  termio        vs  sgtty
     信号：      signal()      vs  sigaction()（BSD 引入可靠信号）

后果是灾难性的：厂商各搞一套，软件无法跨 Unix 移植。这段「Unix 战争」直接给了 Windows NT 崛起的空间。

7.2 POSIX 是「最小公约数」

POSIX（Portable Operating System Interface，IEEE 1003）在 1988 年出台，本质是把双方都有的东西标准化，把有分歧的东西留白或都收进来。

POSIX 保证了什么：
  ✓ 核心系统调用（open/read/write/fork/exec/wait/signal）
  ✓ 基本工具的行为（sh、grep、awk、sed 的基础功能）
  ✓ shell 语法（POSIX shell 子集）
  ✓ C 标准库的系统接口部分
  ✓ 文件系统语义（路径、权限、目录结构）

POSIX 没有规定 / 留下分歧的：
  ✗ 网络（socket 直到 2001 年才进 POSIX，此前是 BSD 的事实标准）
  ✗ 线程模型的细节（pthread 进了，但很多行为是 unspecified）
  ✗ 异步 I/O（POSIX AIO 定义了但实现很差，Linux 基本不用）
  ✗ 设备管理、内核模块、包管理
  ✗ 现代的一切：容器、cgroup、命名空间、eBPF

这就是开篇第三问的答案：POSIX 既救了 Unix 又限制了它。

• 救：它让「写一次、在各种 Unix 上编译运行」成为可能，遏止了生态彻底分裂
• 限制：作为最小公约数，它只能标准化已有的、双方都同意的东西，无法引领创新。所以所有现代特性（epoll、cgroup、namespace、io_uring、eBPF）全都在 POSIX 之外

7.3 Linux 与 POSIX 的关系

# Linux【不追求】POSIX 认证（认证要花钱且限制演进）
# 它的态度是：大体遵守，但需要时毫不犹豫地扩展

# Linux 特有、不在 POSIX 里的东西（前面篇目大量用到）
epoll                    # POSIX 只有 select/poll（31 篇讲为什么不够）
inotify                  # 文件变化通知
cgroup / namespace       # 容器的基础（36 篇）
io_uring                 # 高性能 I/O（32 篇）
eBPF                     # 内核可编程（38 篇）
splice / sendfile        # 零拷贝（32 篇）
memfd_create / pidfd     # 现代进程与内存管理
statx                    # 扩展的文件元数据（04 篇的 btime 靠它）
prctl / capabilities     # 细粒度特权（23 篇）
futex                    # 用户态锁的基础（28 篇）

# 所以「可移植」在实践中是分层的：
#   POSIX 层  -> 能在所有 Unix 上跑（但功能受限、性能受限）
#   Linux 层  -> 只在 Linux 上跑（但能用全部现代特性）

# 实际写代码时怎么处理
# ① shell 脚本：明确目标（17 篇 1.1）
#!/bin/sh        + shellcheck -s sh      -> POSIX，最大兼容
#!/usr/bin/env bash                       -> 用 bash 特性，只要有 bash 就行

# ② C/C++：用特性宏声明需要什么
#define _POSIX_C_SOURCE 200809L          // 只要 POSIX
#define _GNU_SOURCE                       // 要 GNU/Linux 扩展

# ③ Go：build tag 区分平台
//go:build linux
// 用 golang.org/x/sys/unix 而不是标准库 syscall（后者已冻结）

8. 这些设计如何解释前 17 篇的现象

深入层的价值就在这里 —— 前面遇到的那些「别扭」之处，几乎都能追溯到某个设计选择：

9. 面试题

Q：「一切皆文件」的真实含义是什么？它的收益和代价分别是什么？

真实含义不是「所有东西都是磁盘文件」，而是「所有 I/O 资源都用同一组系统调用操作」（open/read/write/close/ioctl）—— 普通文件、管道、socket、终端、块设备、/proc 里的内核数据、eventfd、epoll 实例全都是 fd。

三层收益：工具可组合（grep/awk 不关心数据来源）；权限模型统一（设备访问复用文件权限位）；可脚本化（用 shell 就能改内核参数、配网卡）。

四层代价：

1. 不是所有东西都像文件 —— socket 就挤不进去（没有自然的路径名、连接建立是多步状态机、配置维度爆炸），只能新造 socket/bind/listen/setsockopt
2. ioctl 成了垃圾桶 —— 所有无法用 read/write 表达的操作全塞这里，没有类型安全、无法自我描述、是内核 CVE 高发区
3. 语义泄漏 —— 同一个 read() 在普通文件、管道、socket 上行为不同（能否 seek、是否部分读），这个差异会泄漏到应用代码里
4. 性能天花板 —— 每次 I/O 都要陷入内核 + 查 fd 表 + VFS 分派，这正是 io_uring 和 DPDK/SPDK 旁路方案的动机

Q：为什么 socket 没有被纳入「一切皆文件」？

三个根本原因：

1. 没有路径名 —— open() 需要一个路径，而「TCP 连接」这个概念里没有自然的路径。要造一个（如 /net/tcp/host/port）就得设计整套命名空间
2. 建立连接是有状态的多步过程 —— open() 是一次性原子操作，而 TCP 需要 socket → bind → listen → accept 或 socket → connect 的状态机
3. 配置维度爆炸 —— TCP 有几十个可调项（nodelay、keepalive、缓冲区、拥塞算法），文件抽象里没有地方放，于是有了 setsockopt

值得知道的是：Plan 9 把这件事做彻底了（网络、进程、图形界面全是文件系统路径），证明技术上可行，但没有普及 —— 因为 BSD socket API 已是既成事实，生态惯性远大于设计优雅性。这个规律在 Linux 世界反复出现（systemd 之争、epoll 与 io_uring 的共存）。

Q：为什么 Linux 选宏内核？微内核理论上更优，为什么输了？

结论不是「微内核错了」，而是它的收益在通用场景下不足以抵消成本：

• IPC 开销真实存在 —— 微内核里一次文件读取要经过「应用→内核→文件系统服务→驱动服务→内核→应用」，每一跳都是上下文切换 + 数据拷贝，1990 年代硬件上是数倍差距
• 开发难度被低估 —— 把紧密耦合的子系统（内存管理 ↔ 文件缓存 ↔ 块设备调度）拆成独立进程需要设计大量协议，调试极难
• 驱动生态是决定性的 —— 宏内核里写驱动就是写几个函数并注册；硬件厂商只会为主流平台投入
• 故障隔离收益有限 —— 磁盘驱动崩了即使内核活着，那块盘也用不了，对服务器而言与重启差别不大

但微内核在专用领域赢了：seL4（形式验证）用于航空军事、QNX 用于车载、Fuchsia 的 Zircon —— 这些场景「可验证的安全性」比性能更重要。

Linux 的实际形态是「可扩展的宏内核」：通过内核模块（动态加载）、FUSE（用户态文件系统）、eBPF（受验证器保护的内核扩展）、DPDK/SPDK（用户态驱动），在需要隔离的地方局部获得了微内核的好处 —— 典型的工程务实主义。

Q：为什么 Linux 承诺永不破坏用户态，却对内核内部接口零承诺？

「We do not break userspace」 是 Linux 最强的承诺：系统调用一旦发布，编号、参数、语义永不改变。需要新语义时只能新增，所以有了 open→openat→openat2、clone→clone3、epoll_wait→epoll_pwait→epoll_pwait2 这些「家族」。收益是用户态生态的信任：1995 年编译的二进制在 2026 年的内核上还能跑。

反过来，内核明确声明内部 API 不保证稳定（内核文档里有篇文章标题就叫 “stable API nonsense”）。理由是：内部稳定性会锁死重构能力。这个选择把适配成本转移给了 out-of-tree 驱动作者，从而鼓励驱动合并进主线 —— 进了主线，内核开发者重构时会顺手改你的代码。

与 Windows 正好相反：Windows 长期保持驱动 ABI 稳定，让厂商能发布闭源二进制驱动，代价是内核难以重构。Linux 上 NVIDIA 闭源驱动每次内核升级可能要重编（DKMS 就是为此而生），而进了主线的驱动永远开箱可用。

对 Go 服务的意义：因为系统调用 ABI 永不变，静态编译的二进制能在任何较新内核上跑（scratch 镜像可行）；但用新特性时要做探测（ENOSYS 就回退），Go runtime 自己就大量使用这种模式。

Q：POSIX 是谁和谁的妥协？为什么现代特性都不在 POSIX 里？

POSIX 是 AT&T System V 和 BSD 两大阵营的妥协。1980 年代 Unix 分裂成互不兼容的两派，同一件事有两套 API（ps -ef vs ps aux、SysV IPC vs socket、signal() vs sigaction()），软件无法跨 Unix 移植 —— 这段「Unix 战争」直接给了 Windows NT 崛起的空间。

POSIX（1988）的本质是最小公约数：把双方都有的标准化。所以它只能标准化已有的、双方都同意的东西，无法引领创新。

这就是为什么所有现代特性都在 POSIX 之外：epoll、inotify、cgroup、namespace、io_uring、eBPF、splice、statx、futex、capabilities 全部是 Linux 扩展。POSIX 只有 select/poll（31 篇会讲为什么不够用）。

实践含义是可移植性分层：写 POSIX 层能在所有 Unix 上跑但功能与性能受限；用 Linux 层只能跑在 Linux 上但能用全部现代能力。Linux 不追求 POSIX 认证（认证花钱且限制演进），态度是「大体遵守，需要时毫不犹豫扩展」。

Q：什么是「机制与策略分离」？为什么它重要？

内核提供机制（能做什么），用户态决定策略（应该怎么做）。

三个例子：epoll 只告诉你哪些 fd 就绪，不规定并发模型 —— 单线程事件循环（nginx/redis）、线程池 + 每线程一个 epoll（Go netpoller）、协程调度都能基于它；cgroup 只提供资源限制，不规定资源策略 —— systemd 定义服务默认配额，Docker 定义容器模型，K8s 定义 requests/limits 和 QoS 分级，内核对这些概念一无所知；调度器提供 nice 和权重，但不定义「哪个业务更重要」。

价值在于机制稳定、策略可以演进：epoll 接口十几年没变，但基于它的并发模型从「每连接一线程」演进到了协程；cgroup 接口稳定，但编排系统从 Docker 演进到了 K8s。

这也是 systemd 争议的核心之一：批评者认为它把大量策略（日志格式、DNS 解析、时间同步）打包进基础层，破坏了这个原则、让用户失去替换自由；支持者认为某些策略的统一本身就是价值。

Q：Unix 的「小工具 + 文本管道」哲学在今天还成立吗？

核心成立，但「文本」这一层已经在演进。

「工具必须简陋」的原因是可组合性要求接口窄 —— grep 只过滤行，所以它能出现在任何管道的任何位置；如果它内置排序、统计、格式化，就会与其他工具职责重叠、输出格式变复杂、下游更难解析。这是个深刻的工程原则：功能强大的组件难以组合，因为它们对上下文有更多假设。

文本作为通用接口的收益是人类可读（每一步都能肉眼调试）、任何语言都能参与、无需共享库或 IDL。代价是解析脆弱（ls 输出不可解析）、无类型、结构化信息被压平、以及大量 fork 的性能开销。

PowerShell 做了反向选择（管道传对象）：更可靠、有类型，但耦合到一个运行时。而 Unix 的松散性让一个十行 Python 脚本、一个 C 程序、一个 curl 都能无缝插进管道。

今天的答案是把 JSON 作为新的通用接口：kubectl -o json | jq、docker inspect | jq、ip -j addr | jq、journalctl -o json。这恰恰印证了 Unix 哲学的核心不是「文本」，而是「通用接口 + 小工具组合」 —— 接口从纯文本演进成 JSON，哲学本身没变。

小结

• 理解设计必须先理解约束：Unix 的「简单」源于 8KB 内存的现实和 Multics 过度设计的教训，不是审美选择
• 用 C 重写内核（1973）是最关键的转折 —— 带来可移植性，也带来了五十年的内存安全代价
• 「一切皆文件」= 统一的系统调用接口，收益是可组合、权限统一、可脚本化；代价是 socket 破例、ioctl 成垃圾桶、语义泄漏、性能天花板
• socket 挤不进这个抽象：没有路径名、连接是状态机、配置维度爆炸。Plan 9 做彻底了但没普及 —— 生态惯性 > 设计优雅
• 「组合优于集成」要求接口窄 —— 工具「简陋」是可组合性的前提；文本接口的代价正在被 JSON 缓解
• 机制与策略分离：epoll 不规定并发模型、cgroup 不规定资源策略 —— 机制稳定，策略才能演进
• 微内核不是错了，是收益在通用场景下不够 —— Linux 用模块/FUSE/eBPF/用户态驱动局部获得了它的好处
• 用户态 ABI 永久稳定，内核内部 API 零承诺 —— 前者换来生态信任，后者换来重构自由并鼓励驱动进主线
• POSIX 是 System V 与 BSD 的最小公约数：救了 Unix 生态，但无法引领创新，所以现代特性全在它之外

下一篇讲 从按下电源到 shell 提示符：固件 → 引导器 → 内核解压 → start_kernel → PID 1 → 登录 → shell，每一环为什么必须存在、能不能省掉，以及 initramfs 为什么被发明（这条线索会回收 03 篇的 usrmerge 和 11 篇的 fstab）。