LWN：拯救Itanium的尝试！

关注了就能看到更多这么棒的文章哦～

The push to save Itanium

By Jonathan Corbet
November 9, 2023
ChatGPT translation
https://lwn.net/Articles/950466/

在内核中添加代码相对容易；然而，要在之后删除该代码就更为困难了。最近的一个例子就是 ia64（“Itanium”）架构的故事，该架构的支持在 6.7 合并窗口期间被移除。这个移除动作让一小群忠实的 ia64 用户感到不满，并希望能在一年后恢复该支持。

到了 20 世纪 90 年代末，32 位处理器逐渐无法继续支撑许多应用程序，从而走向生命劲头。主要是 32 位无法满足逐渐出现在高端系统上的内存 size 需求。作为回应，英特尔启动了一个名为“Merced”的计划，旨在创建 x86 的继任者。这是一种与英特尔之前销售的任何东西完全不兼容的 RISC 体系结构。但由于是英特尔，因此它被认为将成为下一个重大突破。

当时，关于这种新架构的信息都受到保密协议的约束，远远不足以让 Linux 开发人员确定何时能够将内核移植到 Merced，甚至是否可能移植。这是在英特尔进行对Red Hat的投资之前的事情，这标志着大量资金进入 Linux 的开始。有可能 Linux 会被排除在这款被我们可靠地告知将成为未来计算的处理器之外，从而只支持 Windows 和专有的 Unix。

当然，最终事情并未按照这种方式发展。英特尔成为 Linux 的最早支持者之一，并确保在一个名为Trillian的项目名称下，让这种新架构很好地支持了 Linux，最终被命名为 ia64（或在销售文献中称为“Itanium”）。最初的 Itanium 支持进入了 2000 年初的 2.3.43 开发内核版本中。看起来我们的 Linux-on-Itanium 未来的道路光明且清晰。

然而，唯一的问题是事情没有按照计划走下去。早期的 Itanium 系统未能达到炒作中承诺的速度。与此同时，AMD 创建了 x86-64 体系结构，增加了 64 位操作的能力，同时尽量保持与大量部署的 32 位软件的兼容性。这种新架构迅速赢得了市场，迫使英特尔效仿 AMD 的步伐；Itanium 最终成为几乎被遗忘的角落。一些系统有被销售出去，并且英特尔继续多年都在制造这些 CPU，但市场有限。Red Hat 在 2010 年放弃了 ia64 支持。

尽管如此，ia64 体系结构代码在内核中得到了维护，只是相关的兴趣迅速减弱。近年来，ia64 代码经常被视为对内核开发的拖累。在 ia64 代码中发现的一个缺陷在一月份被追踪到后，内核开发人员开始更加认真地讨论是否完全移除对该架构的支持。当时进行了一些讨论，一些业余用户对这个想法表示了不满，但当时没有做任何更改。

然而，这个话题在 5 月份卷土重来，当时 Ard Biesheuvel 推动从内核中删除ia64支持，称该架构妨碍了他在 EFI 子系统中的工作：

作为一个维护者，我觉得很不好意思要求贡献者针对 Itanium 平台构建并且测试其更改，并且对大多数人来说进行引导测试是不切实际的要求，即使是有一些人愿意提供硬件设备来来进行这种测试的情况下。总的来说，在远程访问的情况下进行内核或引导加载程序（bootloader, 也就是 EFI 组件所在的地方）的修改是很棘手的。

虽然我知道至少有 2 个人（抄送名单上的）在 Itanium 上测试软件并为其打包，但我认为真正的用户已经没有了，既然如此，是否值得要求人们在这方面花费时间和精力？

在那次讨论中，Debian ia64 移植版的维护者 John Paul Adrian Glaubitz 建议保留 ia64 支持，直到下一个长期支持的内核发布之后，然后可以放弃它。他说，这样可以最大程度地延长 ia64 对剩余用户的支持时间。事情似乎是这样发展的：在 6.7 合并窗口期间，ia64支持被移除。对于 Linux 来说，ia64 的故事现在已经结束。

然而情况并非如此。在 ia64 支持从内核中消失后不久，Frank Scheiner 向邮件列表投诉，表示他和其他人一直在努力解决这个架构的问题，却看到它被移除。Linus Torvalds 回应道，他愿意看到它再次回归—不过是在一段时间后：

因此，我愿意来进行“我们是否能够复活它”的讨论，但不会立即做这个事情—更像是“看，我们已经在代码仓库外维护它一年了，其他基础设施仍然存在，对内核的其余部分没有影响，我们能否再试一次”？

Scheiner 对ia64支持的移除并不完全满意，但 Glaubitz 描述这个一年的计划是“非常合理的”。

因此，那些想要继续支持这个架构的业余爱好者，在此之前已经面临了艰巨的任务，现在看到挑战变得更加严峻。在主线内核不断演进并解除了以前由于需要维持 ia64 运行而被阻挡的那些改动的情况下，在代码树外维护这个架构的支持对于胆小的人来说并不是一项容易的任务。并且使事情变得更加复杂的是，正如 Tony Luck 在 5 月份指出的那样，未来的内核变更可能在被向后移植（backport）到稳定内核来进行更新时，会在那些内核中破坏 ia64。由于在稳定更新上工作的人无法测试 ia64 系统（即使他们愿意），这样的问题可能会很长时间都不被注意到。

在 ia64 恢复的条件之一是 Torvalds 提出的：“其他基础设施仍然存在”。ia64 爱好者们没有忽略这一点，因此当 Adhemerval Zanella 提议从 GNU C 库（glibc）中删除 ia64 支持时，他们感到担忧—这是其他基础设施中最重要的一部分。Zanella 指出 ia64 移植的状况不佳，存在一些似乎难以解决的问题。Scheiner 回答道，也许可以为 libc 库的测试提供少量的 ia64 机器，并申请更多时间来解决一些问题。

然而，Zanella 随后提出了删除ia64支持的补丁。Scheiner 回应道：“这样的速度让我感到非常惊讶，我希望没有必要急于删除它”。然而，其他开发人员，包括Joseph Myers、Florian Weimer以及 glibc 的维护者Carlos O'Donell，都支持删除 ia64 支持。因此，不出意外的话，很可能会在 2.39 版本中看到真正被删除，该版本预计将于明年 2 月发布，或者最迟在下一个版本中看到。

这毫无疑问对 ia64 的支持者提出了更高的要求。虽然绝不应低估一群坚定开发者能够取得的成就，但基本可以得出结论，ia64 的内核支持已经彻底消失。有些人可能会对此感到失望，但这也是一个向社区证明是否值得不遗余力地保持一个架构，即使它以前没有太多用户，现在几乎没有用户了。这种支持，可以说，本来可以在多年前移除而不会引起太大不适，但是从内核中删除代码是一项困难的任务。正如在这里所见到的，有时还是能做到删除代码的。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～