还记得 a.out 二进制文件 吗？它们是 Linux 内核的文件格式，直到 1995 年左右 ELF 取代了它。ELF 更好。它允许您将共享库加载到内存中的任何位置，而 a.out 二进制文件需要您注册共享库的位置。在小规模下这没问题，但是当您需要处理越来越多的共享库时，它会变得越来越令人头疼。但是，在 ELF 成为标准默认格式 25 年后，Linux 源代码树中仍然支持 a.out。

最近，Borislav Petkov 建议在源代码树中弃用它，并考虑在确定没有剩余用户时将其删除。他发布了一个补丁来实现弃用。Alan Cox 也评论说：“在不太可能的情况下，如果有人确实拥有他们离不开的 a.out 二进制文件，他们也可以完全在用户空间中编写一个作为 ELF 程序的 a.out 加载器。”

Richard Weinberger 对弃用 a.out 没有异议，并正式批准了 Borislav 的补丁。

事实上，这个问题碰巧在事后 25 年后的今天出现是有原因的。Linus Torvalds 指出

我更愿意先尝试弃用 a.out 核心转储……实际上，这是真正损坏的部分，不是吗？

事实上，我很乐意完全弃用 a.out，但是如果有人 _确实_ 抱怨，我希望能够恢复它，但不要包含核心转储。

因为我认为任何人关心 a.out 核心转储的可能性基本上为零。而我们有一些仍然是 a.out 的奇怪旧二进制文件的可能性略高于零。

因此，如果这是一个分两个阶段进行的事情，我会更高兴，首先我们完全删除 a.out 核心转储，然后分别弃用甚至运行 a.out 二进制文件。

因为我认为我们所有已知的 *错误* 都是与核心转储代码相关的，不是吗？

删除它看起来很简单。附加了未经测试的补丁。

然后我会对您的“让我们完全弃用 a.out”作为第二个补丁感到更加高兴，因为我认为这是一个不相关的问题，并且更有可能有人插话说“嘿，我有一个动态生成可执行文件的序列，我使用 a.out 是因为它比 ELF 简单得多，现在它坏了”。或者诸如此类的事情。

Jann Horn 检查了 Linus 的补丁，并提出了如果核心转储被移除，a.out 的其他一些组件也将不再被使用。他建议这些东西也可以在同一个 git 提交中删除，而不会冒着任何人抱怨的风险。

Borislav 对 Linus 的方法有点怀疑——正如他所说，“谁知道这些年来还有什么东西已经比特腐烂了”。但是，他并没有怀疑到提出替代方案。相反，他对 Linus 说，“最简单的方法是您现在直接应用您的补丁，并在其提交消息中添加我们正在进行的 a.out 淘汰策略，以便人们意识到我们正在做什么。”然后，他补充说，架构维护者可以根据具体情况从他们的架构中删除 a.out 核心转储支持，然后 Borislav 可以在稍后继续完全弃用 a.out。

Linus 说他可以接受，但他也说他很乐意在 Linus 的核心转储删除补丁之上立即应用 Borislav 的 a.out 弃用补丁。他不介意有时间延迟，只要这两个补丁在有人对其中一个提出异议时可以独立撤销即可。

此时，各个架构维护者开始评论他们在特定架构上的 a.out。

Geert Uytterhoeven 说，“我认为可以安全地假设没有人还在 m68k 上运行 a.out 二进制文件。”

而且，Matt Turner 说，“我不知道有什么理由要在 alpha 上保留 a.out 支持。”

然而，事实证明 alpha 架构比 Matt 最初想象的更困难。Linus 研究了这个端口，发现仍然保留了很多 a.out 支持。他说，该端口的某些部分甚至在没有 a.out 支持的情况下都毫无意义。因此，与简单的截肢相比，alpha 代码实际上需要进行更多的精简。

Måns Rullgård 也评论说，“任何运行 Alpha 机器的人也可能有一些他们希望使用的旧 OSF/1 二进制文件。删除此功能将是一种遗憾。”

这实际上让 Linus 停下了脚步。他回复了 Måns

如果情况是这样，那么我们就必须为 alpha 保留 a.out，因为那是 OSF/1 二进制格式（至少是我们支持的唯一一种 - 我不确定更高版本的 OSF/1 是否最终采用了 ELF）。

我想我们可以这样做，但问题是人们是否真的有 OSF/1 二进制文件。早期，它作为已知的良好二进制文件的来源来用于测试非常有用，但我不太相信它仍在被使用。

这不像我们无法本地访问 OSF/1 二进制文件（好吧，_确实_ 有一些特殊的二进制文件没有开源版本，但它们中的大多数需要比 Linux 曾经实现的更多的系统端支持，据我所知）。

Måns 回复说，“我可以很容易地想象有人保留 Alpha 机器仅仅是为了能够运行一些（旧的）应用程序，这些应用程序（对他们而言）仅适用于 OSF/1。在 Linux 而不是 Tru64 上运行它们带来了在其他方面成为现代系统的优势。”

Matt 说他不知道 alpha 上的这种情况，并同意可能需要在该架构上继续支持 a.out，只是为了那些需要它的剩余用户。

作为一个实际的例子，Arnd Bergmann 回忆说，“我听说的主要历史用例是在 Alpha Linux 上运行 Netscape Navigator，在开源版本出现之前。今天这样做来连接开放互联网可能有点毫无意义，但可能还有其他用例。”

他还补充说

查看内核中的系统调用表……我们似乎支持应用程序集所需的特定子集，而不是更多。旧的系统调用……被列出但未实现，对于大多数后续调用也是如此……只有中间的那些在那里。这也表明它从来没有真正作为一个通用的仿真层工作，而只是为了特定的应用程序集而存在。

就任何人可能抱怨失去 a.out 支持而言，Arnd 还指出，“osf1 仿真在 linux-4.13 和 linux-4.16 之间被破坏，但没有人注意到。”

Linus 回复说

是的，它从未支持任意二进制文件，特别是考虑到运行这样的东西通常还有很多其他问题（例如文件系统布局等）。它对于正常的、行为良好的东西来说效果很好，但从来都不是一个完整的 OSF/1 仿真环境。

我 _怀疑_ 现在没有人真正运行任何 OSF/1 二进制文件了，但验证这一点显然是好的。您关于 timeval 处理被破坏的论点 _可能_ 表明了这一点（或者可能只是意味着很少有应用程序关心）。

基于这些令人放心的考虑，Linus 说，“我认为我们应该尝试删除 a.out，看看是否有人注意到。”

讨论简短地继续进行，但看来 a.out 最终将在不久的将来被删除。

让我着迷的是，如果即使找到一个用户仍然依赖它，也要坚持继续支持古代功能。如果即使只有一个人提出使用 a.out 的有效用例，Linus 也会将其保留在内核中。与此同时，如果没有用户站出来，Linus 也不会假设他们可能秘密地潜伏在野外某个地方——他会杀死这个功能。仅仅使用古代功能是不够的，用户需要成为社区的积极成员——或者至少，足够积极地报告他或她希望继续使用该功能。在这种情况下，Linus 可能会邀请该用户维护所讨论的功能。

注意：如果您在上面被提及并希望在评论区上方发布回复，请将您的回复文本发送消息至 ljeditor@linuxjournal.com。