为什么给 Linux 添加新接口这么难？从“创建并打开目录”的内核争论谈起

在 Linux 内核开发的世界里，“添加或修改用户空间接口（ABI/API）”被公认为是风险最高、决策最艰难的领域之一。Linux 内核有一条由 Linus Torvalds 亲自下达且绝对不可触碰的铁律：“We never break userspace”（绝对不能破坏用户空间）。

一个内核内部的算法写错了，随时可以提交 Patch 重构；但一个系统调用、标志位（Flag）或文件接口一旦随 mainline 发布，就彻底变成了“化石”。即便最初的设计是个 Bug，只要有应用程序依赖了这个行为，内核就必须“背锅”维护一辈子。

为了避免给开发者挖坑，在设计一个新的用户空间接口时，内核社区通常需要极度艰难地权衡以下核心问题：

一、 探知机制（Feature Discovery）与“防呆”设计

应用程序该如何知道当前运行的内核是否支持这个新接口？这是设计 API 时首要考虑的问题。

• 好的接口（自发现性）： 如果旧内核不支持新特性，调用时必须能够明确且立即报错（如返回 EINVAL 或 ENOSYS），从而让应用优雅地降级（Fallback）到老旧逻辑。

• 坏的接口（陷阱/Minefield）： 旧内核不报错，但默默做出了与新语义完全不符的危险操作。这会迫使应用开发者编写极其复杂且容易出错的“防御性代码”。

【案例分析：mkdirat2() 与 O_CREAT|O_DIRECTORY 的争论】

 

近期，内核开发者 Jori Koolstra 试图解决 Linux 无法通过“单次无竞态条件调用”同时创建并打开目录的问题。Christian Brauner 提出直接复用现有 open() 的标志位组合 O_CREAT|O_DIRECTORY。

 

然而，这一方案遭到了 Christoph Hellwig 和 Pedro Falcato 的强烈反对。因为在历史上的不同 Linux 内核版本中，这个标志组合的行为极其混乱：

 

• 早期内核：若名称不存在，调用 open() 竟然会默默创建一个普通文件；

• 5.7 内核：虽然开始返回错误，但依然会在磁盘上创建该文件；

• 6.4 内核：才由 Brauner 补丁修复为一律返回 EINVAL 报错。

Hellwig 强调，我们需要的是“自建发现机制”的接口。由于大量旧版 LTS 内核并未补充（backport）6.4 的修改，一旦新应用使用该标志，运行在旧内核上时就会触发不可预测的错误，甚至破坏文件系统结构。

二、 统一接口 vs. 引入新系统调用的两难

当需要新功能时，是修改现有 API（如给 open() 拓展 Flags），还是直接开辟一个新的系统调用（如 mkdirat2()）？

• 修改老接口： 优点是能“免费”复用现有系统调用的大量特性（如路径解析限制、文件描述符管理），且不增加系统调用表的臃肿度。缺点是容易触碰历史遗留行为的“雷区”。

• 引入新系统调用： 优点是语义干净、没有历史包袱，在旧内核上必定直接返回 ENOSYS（未实现），天然具备极佳的自发现性。缺点是容易招致社区对“系统调用膨胀”的审查。

【案例分析：新系统调用与现有标志位的抉择】

 

Koolstra 最初曾尝试引入新的系统调用 mkdirat_fd()（后改为 mkdirat2()），但社区顾虑重重。Brauner 认为增加新系统调用是浪费资源，完全可以通过拓展 open() 解决。

 

但针对老内核的兼容隐患，Neil Brown 甚至建议为更现代的 openat2() 引入一个新标志 OPENAT2_NEW_COMBINATION，用于强制拒绝任何未识别的标志，以确保新特性在旧内核上能被安全拒绝。各方在“扩展老接口”与“开辟新接口”之间的拉锯，体现了 API 架构选择的艰难。

三、 跨 UNIX 体系与 POSIX 标准的可移植性

Linux 并非孤立存在，许多应用需要运行在 FreeBSD、OpenBSD、macOS 等 UNIX 体系上，甚至遵循 POSIX 标准。

如果 Linux 私自为某个标志位组合赋予了新语义，而其他 UNIX 系统对其有完全不同的解释，或者根本无法达成一致，就会导致整个开源生态的 API 语义碎片化。跨平台软件（如 Nginx、PostgreSQL、Git）的维护者将不得不编写大量的 #ifdef 宏和针对不同 OS 的特殊逻辑。

【案例分析：FOSS UNIX 领域的语义碎片化】

 

Pedro Falcato 在讨论中指出，O_CREAT|O_DIRECTORY 在整个开源 UNIX 阵营中有大约 5 种不同的行为模式。POSIX 标准委员会几乎不可能对这种语义达成一致。如果 Linux 强制赋予其“创建并打开目录”的含义，编写跨平台可移植代码的用户将面临巨大的安全隐患和维护噩梦。

四、 用户空间安全基础设施的阻碍（如 Seccomp）

即便设计出了一个逻辑完美的系统调用，现实中的安全机制也可能成为新 API 推行的“绊脚石”。

现代 Linux 生态广泛依赖沙盒与安全过滤机制（如 Docker/Kubernetes 容器、Chrome Sandbox、systemd 隔离中的 seccomp()）。这些安全策略通常采用严格的系统调用白名单。

• 当内核引入全新的系统调用时，旧的 Seccomp 策略无法识别它，会直接通过 SIGSYS 信号杀掉调用进程。

• 这导致许多应用程序为了防范崩溃，在生产环境中数年内都不敢采用新的系统调用。

【案例分析：Seccomp 对 openat2() 的阻碍】

 

在讨论是否应将“创建并打开目录”的功能仅限定在较新的 openat2() 系统调用中时，Koolstra 本人提出了现实担忧：目前有相当多的 seccomp() 配置仍然默认拦截 openat2()。如果强制绑定新 API，会导致该特性在大量实际生产环境（如容器）中根本无法使用。

结语

维护长期的接口兼容性是一项极其艰难的技术考量。确保“新内核不破坏旧应用”已是不易，而避免“新应用在旧内核上崩溃”则更为棘手。

正如内核社区关于“创建并打开目录”的争论所展示的那样：开发者们对 Flags 组合的唇枪舌剑，并非无谓的推诿，而是因为每个人都深知只有一次做对决定的机会。一旦接口随内核版本发布，它就再无回头路可走。这种近乎苛刻的谨慎，正是 Linux 能够在过去三十年里保持惊人稳定性与庞大生态的最核心屏障。