Linux 能力 是内核开发中更具流动性且定义较少的领域之一。Linus Torvalds 通常不惮于违反 POSIX 标准，如果他认为有更好的方法。然而，在文件系统能力方面，没有标准可供违反。我们所拥有的最好的是一份在正式发布前被废弃的 POSIX 草案文件。因此，实际上，任何有好主意的人都可以出现并对内核的这一部分进行重大更改。

文件系统能力指的是比传统选择（以普通用户身份或 root 身份运行）更细粒度的权限集。

最近，Eric W. Biederman 和 Andy Lutomirski 发现他们自己正从相反的方向处理文件系统能力。Eric 希望允许已被授予一组能力的进程使用更受约束的能力集来调用系统调用。据推测，目标是通过防止系统调用被滥用于恶意目的来提高安全性。并且，Andy 希望允许一个进程允许一个完全独立的进程代表它执行系统调用。这可能允许形成系统调用服务，以集中所有系统调用的使用，并使其更容易保护这些使用。

讨论来回进行。正如 Eric 后来澄清的那样，Eric 的想法实际上比乍看起来更广泛——他想将 POSIX 能力的 Linux 实现转换为“真正的能力”（Real Capabilities）。“真正的能力”一词指的是早于 POSIX 能力的计算机科学概念。它指的是向进程授予某种令牌的想法，该令牌允许它对特定对象执行指定的操作。

最终，关于能力或该领域任何新补丁的内容，在它们进入内核之前都不可能真正清晰。在此之前，总是存在它们会违反某些重要内容或方向错误的可能性。但是，看到 Eric 和 Andy 以及许多其他人试图弄清楚这一点很酷。

Linux 中一个反复出现的问题是对向后兼容性的需求。实际上，这几乎影响了整个开源世界，但 Linus Torvalds 对 Linux 内核在这个问题上采取了特别严格的立场。如果野外存在一个编译过的用户软件，它依赖于内核功能，即使是一个愚蠢的内核功能，那么未来的内核也必须支持该功能，以便该用户软件在内核升级后能够继续运行。

这是有道理的。但正如 Andy Lutomirski 最近所说，结果是一批仅为支持旧程序而存在的功能。他说，通过将这些功能永久地带入未来，较新的软件面临意外使用这些功能甚至依赖于这些功能的风险。

他提议允许新软件显式关闭这些兼容性功能，但这结果比他最初想象的要复杂。具体来说，他的核心想法之一——授予较新软件关闭 vsyscall 页面的能力——并不容易安排。Andy 最初的想法是让编译器在编译时识别使用较新版本 libc 的软件，然后让该软件选择在运行时禁用 vsyscall。但是，他没有看到实现这一目标的良好方法，并且 Brian Gerst 指出 vsyscall 是全局共享的，不能为单个进程关闭。

实际上，这并非 100% 正确。尽管 Andy 同意 vsyscall 是全局共享的，但执行它的机制都在内核中模拟，并且这些机制可以在每个进程的基础上禁用。

Rich Felker 提出了另一种解决 vsyscall 全局可用性的方法。他说内核可以简单地取消映射所有执行 vsyscall 的方法。任何试图访问它的旧软件都会生成页面错误，内核可以捕获该错误并仅为该程序模拟 vsyscall。

但是，Andy 没有采纳这个想法。他说现代 instrumentation 工具可能想要读取调用的目标，而页面错误会阻止这一点。Andy 说，任何 vsyscall 解决方案都必须保持对这些工具的兼容性。

另一方面，正如 Rich 所说，这些现代工具在实践中可能永远不会用于旧的二进制文件。即使使用了，也可能为每个用例编写特定的内核解决方法，其侵入性比试图提出 vsyscall 的完整解决方案要小。

这是一场激烈的辩论，复杂之处在于很难确定是否有人真正在运行依赖于这个或那个内核兼容性功能的旧二进制文件。但是，Andy 明确表示，清理兼容性功能并不是他的主要目标，而主要是消除潜在的安全漏洞。显然，Google 的 Project Zero 已经发现了更多漏洞：http://googleprojectzero.blogspot.com/2015/08/three-bypasses-and-fix-for-one-of.html。

Linux 帧缓冲 曾经是创新的堡垒，现在却面临被淘汰的境地，取而代之的是 Direct Rendering Manager (DRM) 子系统。fbdev 维护者 Tomi Valkeinen 已要求所有人停止提交新的 fbdev 驱动程序，并将精力转向 DRM。

它并不像您想象的那么没有争议。事实证明，正如 Thomas Petazzoni 等人所说，为 fbdev 编写非常简单的驱动程序仍然比为 DRM 编写更容易。仅就代码行数而言，Geert Uytterhoeven 注意到最简单的 fbdev 驱动程序只有几百行代码，而最简单的 DRM 驱动程序可能需要数千行。

没有人认为这将是一个永久性问题。如果有的话，讨论强调了需要为 DRM 编写一些支持库，并帮助加速最终消除 fbdev。