LWN：Linux kernel中如何废弃不用的软件和硬件平台！

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

Software and hardware obsolescence in the kernel

By Jonathan Corbet
August 28, 2020
LPC
原文来自：https://lwn.net/Articles/829733/
DeepL assisted translation.

在内核中添加代码以支持新的硬件，相对来说是比较容易的。删除那些不再有用的代码可能更难，主要是因为很难知道什么东西在何时真的不再有用了。在 2018 年从内核中删除了对八种架构的支持的 Arnd Bergmann 就很清楚这有多难。在 2020 年的 Linux Plumbers 大会上，他主持了两场会议，专门讨论过时的软件和硬件的话题。他说，只要稍加努力，应该可以更好地知道什么时候可以删除某些东西。

The software side

他说，过时的硬件（obsolete hardware），定义上来说是不再生产的设备，通常是因为它们已经被更新的、更便宜的、更好的产品所取代。过时的硬件可能仍然有用，而且往往会保持使用很长一段时间，但人们很难知道是否某种特定的设备仍然有人在使用。过时的代码（obsolete code）有点不同，它所支持的硬件可能还在生产中，但它的所有用户都在运行旧的内核，而且永远不会升级。在这种情况下，代码可以被删除，因为没有人从它的持续维护中获益。

Bergmann 的建议是创建一种方式来记录内核中的哪些代码仅仅是为了支持过时的硬件；具体来说，它将记录与该硬件相关的内核配置符号。对于每个符号，文档会描述为什么它还在使用，以及这种情况预计会持续多久。移除这个支持会发生什么后果（例如对其他依赖它的驱动程序的影响）以及移除它的好处都会被记录下来。

有很多群体会受到这个变化的影响。例如，内核保留了对一些业余爱好者平台的支持；这些平台包括一些没有商业价值，但却有很多业余爱好者的处理器架构。内核仍然支持一些 Sun 3 工作站型号；他不知道是否有人真的在运行这样的系统。只要有人愿意维护，内核开发者一般都喜欢让业余爱好者的平台继续存在。

还有一些平台的用户很少，但这些用户可能真的需要它们。这些包括各种类型的嵌入式系统、工业控制器、军事系统等等。还有一些系统显然在未来会走向淘汰。这些包括 32 位架构，虽然现在仍在大量使用，但最终会消失。使用 Big Endian byte order 的系统在过去十年中下降了 90%，最终可能会完全消失。

那么这类信息应该记录在哪里呢？他提出了几个选择，包括在文档目录下新建一个文件、或在定义相关配置符号的 Kconfig 文件中、在 wiki.kernel.org 的某个地方、或者完全在其他什么地方放置。根据会议系统中的投票，仅有超过一半的与会者表示倾向于在内核 tree 中建立这样一个文件。

这时 LWN 编者不得不跳出来问，这个想法与内核的 feature-removal-schedule.txt 文件相比如何。这个文件是在 2005 年添加的，作为一种警告用户即将消失的特性的方式；这个文件本身在 2012 年被 Linus Torvalds 厌烦之后被删除。现在讨论的新文件，跟它的命运为什么会有不同呢？Bergmann 回应说，这个文件不会是移除支持的时间表；相反，它将是一种记录支持至少需要保留一定时间的方式。受影响硬件的用户可以很容易地在任何时候更新该文件，以向社区保证它们仍然存在。作为在内核中保留支持的理由的文件，它将会更有用。

Florian Weimer 问，如果这个建议被采纳，对用户空间会有什么影响；答案是 "没有"。Bergmann 说，用户空间接口属于不同的类别，在删除它们之前需要克服更高的门槛。这个文件将涵盖硬件专用代码。Mike Rapoport 补充说，一旦明确没有人在相关硬件上运行上游内核，这将是一种知道用户何时不受影响的方法。

Catalin Marinas 建议为支持过时硬件的代码创建一个 CONFIG_OBSOLETE 标记，但 Will Deacon 对这个想法很紧张。他最近在 32 位 SPARC 机器的页表代码上做了一些工作；他没有收到关于这些改动的 review 反馈，但当各种持续集成系统测试它们时，他确实得到了报告。如果使用 CONFIG_OBSOLETE 标记的话，可能会被这类系统的维护者认为是代码不再需要测试的信号，从而大大降低测试覆盖率。

Bergmann 补充说，32 位 SPARC 是一个有趣的案例。他说，人们一直在该代码中发现严重的错误，System V 进程间通信根本无法正常工作。有很多对 32 位 SPARC 用户空间的测试，但这些测试都是在 64 位内核上运行的，在此环境中这些问题并不存在。他相信这段代码的剩余用户很少（假如不是 0 的话）。

Len Brown 又回到了旧的 feature-removal-schedule.txt 文件的问题上，询问从那次经历中得到了什么经验。Bergmann 回答说，他提议的文件旨在帮助为移除做更好的规划。他说，要想弄清楚是否有人在使用某个特定的功能是一件很费劲的事；以这种方式记录有哪些用户，将大大减少工作量。Laurent Pinchart 补充说，这些信息对于开发者来说也是很有用的，他们可以找到某个硬件的用户来测试提议的改变。

在会议即将结束时，James Bottomley 指出，这种问题经常出现在 SCSI 子系统中，因为 SCSI 子系统往往会 "keep drivers forever"。不过最终，内部 API 的变化会迫使人们讨论删除特定的驱动程序，但这每次都是一件很难做到的事情。人们总说如果事实证明确有需要的话，被移除的驱动可以随时从 Git 历史中复活出来，但说起来很容易，真正实践时并不顺利。

Bergmann 在最后指出，某个驱动的维护者通常知道没有人在使用某个设备。但一旦发生这种情况，维护者往往也会离开，带着这些信息离开。这时，没有人负责删除相关代码，而且可能会持续多年。

System-on-chip obsolescence

Bergmann 在另一场专门讨论片上系统芯片（SoC）产品生命周期的会议上又回到了这个话题。他花了很多时间研究内核中架构支持的各个方面，他了解到如何支持 SoC 演进的信息，以及这对目前内核支持的架构意味着什么。

他说，在内核中，对任何给定 SoC 的支持有五个级别。

1. 完全的上游支持，所有代码都在主线上，所有功能都可以使用，新的内核功能也完全支持。

2. 最小的上游支持，但修复和更新仍然会进入稳定的内核版本。

3. 主线中的更新最多只是零星的，也许修复的内容会进入长期支持的内核中。

4. 不再有上游支持；用户直接从厂商那里获得任何更新。

5. 系统可以运行，但主线内核中没有更新或持续支持。内核中可能还有代码，但不被任何人使用。

对于 SoC 支持来说，最重要的阶段是 bringup 阶段，也就是第一次让 SoC 工作起来的这个阶段；如果可能的话，这种支持应该一直到 "完全支持 "级别。支持的水平通常只会从那里开始下降。人们停止提供更新 patch，最终，这些 update 根本就不再出现了。

在 bringup 时出现的问题往往发生在可以预测到的一些地方，比如最常见的就是 GPU 驱动程序部分的错误。据说最近一段时间情况已经好了很多，越来越多的 GPU 有 upstream support 了。Android patch 可能是另一个症结所在，随着时间的推移，这一点也在改善。上市时间（time to market）很短，以及产品寿命（product lifespan）短也都会成为实现全面支持级别的阻碍。

Bergmann 放了一张图，显示了 2010 年的 "CPU 架构世界图"；可以在他的幻灯片[PDF]的第 6 页看到。

这张图在一个轴向上绘制了从微控制器到数据中心应用的各种不同架构，在另一个轴向上展示了它们更靠近 big-endian 还是 little-endian。这些架构分布在图中不同位置，IBM Z 占据了 big-endian、数据中心的这个角落，而众多的架构如 Blackfin 和 unicore32 则在 little-endian、微控制器的角落。

他说，那个时代有很多架构可供选择，其中很多架构的前景都很好。Arm 架构是只用在手机上的 "小东西"，在当时并不是特别重要。但手机现在看来原来是 Arm 成功的关键。随着手机性能的提高，它能够淘汰其他大部分的产品。

图中中间这部分，就代表了市场上的 SoC 这一部分。这类系统比微控制器（microcontrollers）大，但比数据中心的处理器小。其中有三代产品对 Linux kernel 很重要。第一代，以 Armv5 架构为典型代表，在 2000 年左右问世，现在仍在继续发展；这些都是单处理器系统，内存大小以兆字节为单位。2007 年推出的 Armv7-A 代，一个 SoC 上最多有 4 个内核，内存大小可达 2GB；这一代完全由 Arm 处理器主导。最后，从 2014 年开始的 Armv8-A（以及 x86-64）这一代产品，支持 2GB 以上的内存大小和 64 位处理器。

他也介绍了一下内存技术，指出 DDR3 内存往往是 2-4GB 以下尺寸的性价比最高的选择，但超过这个尺寸就没有竞争力了。这一点很重要，因为第二代处理器无法支持 DDR4 内存。

他说，如果需要极低的成本，那么就要选择第一代处理器，这也是选择第一类处理器的唯一理由。对于大多数其他应用场景来说，正在被 64 位系统所统治，它们正在取代一些厂商的 32 位 SoC。中间这一代的 Armv7-A 正在慢慢被挤出。

Kernel support implications

那么对内核支持有什么影响呢？他先用一张图来说明目前内核支持的机器（machines）有多少；其中大部分机器，此时都是用 devicetree 文件来描述的。剩下的几百种 machine 则需要 board files（也就是以 C 代码形式编写的 machine description）。他建议，所有 board files machine 可能也到了被移除的时候。他说，如果这些 machine 还在使用，那么就会有人把它们转换为 devicetree。

到了 2017 年，很明显，许多架构的生命已经接近尾声；相应地在 2018 年取消了对其中 8 个架构的支持。剩余的架构中有一些看起来也快要停止了。例如，Itanium、SPARC M8 或富士通 SPARC64 处理器可能不会有新产品。目前业界主要凝聚在 x86 和 Arm 架构上。

显然，这些架构在 2020 年及以后会有新的产品问世，所以它们会存在一段时间。还有一些其他架构。其中 RISC-V 架构正在快速增长。IBM Power10 和 Z15 架构还在开发中。Kalray Coolidge 和 Tachyum Prodigy 目前还在开发中，没有内核支持。有一个 64 位版本的 ARC 架构正在开发中，还没有内核支持。目前仍有 Loongson 和 Ingenic 等厂商推出 MIPS 芯片，或许有人会感到惊讶，现在仍有基于 20 年前 Armv5 内核的 SoC 在推出。

他说，big-endian 系统显然正在被淘汰。有一些架构同时支持这两种 endian；大多数架构正在转向只支持 little-endian。SPARC32 和 OpenRISC 没有屈服，但是预计它们的用户将可能在近期迁移到 RISC-V。大约只有 IBM Z 是唯一还在往 big-endian 方向发展的架构。

还有一些新的 SoC 架构正在酝酿中。最重要的是 RISC-V，各个厂商的 SoC 众多。对 RISC-V 的期望值很高，但目前还没有产品在内核上支持。ARC 架构已经存在了 25 年，仍然很活跃，它在微控制器中得到了很多应用。内核中对 32 位 ARC SoC 的支持不多，对即将到来的 64 位版本还没有支持。不过，显然正在开发中。

这一切的发展方向是什么？Bergmann 最后对 2030 年的情况做了一组预测。他说，市场将被 x86-64、Armv8+和 RISC-V 架构所瓜分；任何其他架构都很难找到挤进来的办法。内核 upstream 中对这些架构的支持将继续得到改善。IBM Z 主机仍将有利可图。

而最后的 Armv7 芯片，现在已经发布了，但它们仍然会在 2030 年出货（并且在之后的很长一段时间内使用）。所以 32 位系统在 2030 年以后仍然需要得到支持。基于这些原因以及更多的原因，他预计至少在未来一年内不会看到内核进一步取消架构支持。

在另一方面，还有 128 位的架构，如 CHERI，将崭露头角。这对内核的支持可能是一个巨大的挑战。在移植到 Alpha 架构之前，最初的内核只支持 32 位系统；这种移植是可行的，因为当时的内核还很小。而现在的 kernel 大得多了，并且一直有一个假设，即一个 unsigned long 跟指针的大小相同，由于指针用的非常广泛，所以打破这个原则将是一个痛苦和充满伤痛的经历。要修复这个问题，可能需要由新一代 kernel hacker 来完成了。

全文完

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

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

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