LWN：准备移除掉的一些内核代码！

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

Kernel code on the chopping block

By Jonathan Corbet
January 19, 2023
DeepL assisted translation
https://lwn.net/Articles/920259/

添加到内核中的代码可以在那里停留很长时间。在目前的内核中，有一些代码已经存在了超过 30 年。不过，没有什么是可以永远存在的。内核开发社区目前正在讨论删除掉两个体系架构和一个文件系统，所有这些似乎基本上都不再使用了。但是，正如我们将看到的，从内核中删除代码并不容易，即使删除之后也会有可能要重新考虑。

Not-so-SuperH

日立的 SuperH 架构可以追溯到 20 世纪 90 年代；它是一个 32 位的处理器，面向嵌入式应用。1999 年 9 月，在 2.3.16 版本的内核中首次加入了对 SuperH 的支持（添加了最基本的支持）。虽然在推出后的一些年里很受欢迎，但 SuperH 最终还是被 Arm 取代了。瑞萨（Renesas）公司仍在生产 SuperH 处理器，但不建议在新设计方案中使用。

2015 年左右，有人试图重振这一架构，原因是涵盖了其设计的专利即将到期。于是就设计出了一个名为 J-Core J2 的处理器，希望能作为一个完全开放的硬件（open hardware）。不过，J2 并没有真正发展起来，也许是因为在那个时代人们对 32 位处理器的兴趣正在迅速消退；J-Core 的 news 页面最后一次更新是在 2016 年。Rob Landley 的这一个邮件表明这个项目并没有完全死亡。不过，尽管一个完全开放的处理器很有吸引力，但 J-Core 似乎并不会成为 SuperH 架构的救星。

最近，Christoph Hellwig 发布了一组 patch，从内核中移除 SuperH 架构的支持，他说：

arch/sh 一直比较难处理，因为它支持大量的 SOC，而且大部分甚至还没有被修改切换为使用 device tree 架构。这些 SOC 一般也都过时了，所有的支持代码几乎 10 年都没有维护过，并且 1 年内完全没有修改。

John Paul Adrian Glaubitz 反对删除，并指出他仍在维护 Debian SuperH 的移植版本。"人们一直希望把它干掉，这有点让人失望。对我来说它工作得很好"。Geert Uytterhoeven 补充说，SuperH 的问题其实并不是缺少用户，甚至也不缺少开发者来创建 patch，而是没有维护者来合入这些 patch 了。

这次讨论得出了一个可能结果，Glaubitz 和 Landley 将试图来接管内核的 SuperH 移植维护工作。他们将有自己的工作要做；除其他外，SuperH 需要修改切换到使用 device tree，并删除对许多过时的 CPU 和 board 的支持。但是，如果新的维护者能够让 SuperH 回到正轨，那么它在内核中的日子可能还没有到头。

The last sinking of the Itanic

在 20 世纪 90 年代末，有很多关于英特尔的新处理器架构的讨论，当时它的代号是 "Merced"。这种 CPU 将是未来计算的基础，它将是如此之好，甚至它将迅速取代 x86。但是关于 Merced 的细节很少，而且根本不清楚是否有足够的信息可以为这个架构把 Linux 移植上来。人们普遍担心，英特尔和微软可以通过拒绝公布 Merced 相关的信息，从而在 Linux 开始获得一些真正的商业进展的时候将其排除在外。

不用说，事实并非如此。相反，英特尔在 1998 年成为了 Red Hat 公司的早期投资者。当 Merced（后来被称为 "Itanium"）进入市场时，Linux 对它有一流的支持。Itanium（ia64）架构首次出现在 2000 年初的 2.3.43 开发内核版本中。Itanium 处理器的开发时间很长，当它们被广泛使用时，它们早已被最初由 AMD 开发的 x86-64 所超越了。Itanium 从来不是一个成功的产品线，现在也没有再生产 Itanium CPU 了。

虽然内核中仍然支持 Itanium，但不清楚这将持续多久。最近关于它的未来的讨论是由于 Mateusz Guzik 的一个 patch，他查到了一个 lock 的性能问题，似乎是源于一个只有 Itanium 架构需要的 cpu_relax() 调用。这导致曾经是该架构内核维护者的 Tony Luck 提问说：

现在是时候做这件事了吗？
$ git rm -r arch/ia64

Ard Biesheuvel 表示赞同，并指出他无法进行任何形式的测试来确保 EFI 的改动能够在 Itanium 架构上可用。另一方面，Jessica Clarke 和 Glaubitz 都指出，Debian 还是有一个 Itanium 移植版的；Glaubitz 补充说，Gentoo 也支持该架构。Luck 认为，继续保持这些系统的运行，其实是一种浪费：

是否真的有人在 ia64 上运行生产系统，同时更新到 v6.x 的内核？

如果有，为什么？只要把这台机器报废，换上几乎任何其他的东西。你在短时间内节省下来的电费就足够支持这台新机器的费用。

答案是 "业余爱好者（hobbyists）"，他们希望能让这种系统继续运行。Biesheuvel 同情这些业余爱好者，但还是问：
#+begin_quote
然而，问题不在于你或我如何选择花费（或者说是浪费）他们的时间。问题是， 作为一个社区 ，坚持要求每个为跨架构变革做出贡献的人都必须确保 ia64 或 alpha 等过时的架构不被抛弃，这是否合理。
#+end_quote。

他指出这个话题的原始邮件就是一个例子：由于 Itanium 特有的问题，locking 性能变差，所以开发者需要找到一种方法来加快 locking 的速度并且不要在这个没有人可以使用的处理器上引入一些 regression。也可能不要这么去做。Luck 提出了一个 fix 方案，但 Linus Torvalds 回答说这根本不值得去花这个时间。

目前还没有人确定说可以真正去除对 Itanium 的支持了，所以还不清楚这会在什么时候发生。不过，看起来不会太久了。随着开发者停止对这一架构的最低限度的支持，它就会逐渐变成一个越来越无法维护的状态。对这种不受欢迎的架构的支持已经在内核中存在了 23 年；不可能再继续存在下去了。

JFS

很久以前，journal 日志还是文件系统的热门新功能，而 Linux 没有任何文件系统可以支持它；系统管理员必须比现在来说更加需要熟悉 fsck 工具。这个漏洞首先由 ReiserFS 填补上了，它在 2002 年 2 月初被合并，被包含在 2.4.0.4 版本中。但它很快就被 JFS 所取代了，后者在不到三周后就进入了内核。JFS 来自 IBM，是 AIX 操作系统的主要文件系统；它也支持日志功能。

JFS 从未成为顶级的 Linux 文件系统之一，尽管它确实在一些地方出现过；MythTV 项目仍然在其文档中的一些位置建议可以使用这个文件系统。但是，JFS 多年来没有看到任何实质性的发展，也不清楚是否还有很多用户。Hellwig 指出，JFS 会拖慢 folio 的切换工作，他问是否应该干脆把它删除掉。

这个文件系统似乎没有什么捍卫者。最初在 2002 年加入它的 Dave Kleikamp 仍然被列为它的维护者，他回答说。"很明显，我已经很久没有在 JFS 上投入什么精力了，如果它被删除掉，我也不会怀念它"。目前还没有发布 patch 来进行删除，但是，如果没有来自什么人或组织来慷慨地承担对 JFS 的辩护工作的话，我们可以期待它至少在不久的将来会被标记为 orphaned （孤儿）状态。

The zombie pktcdvd driver

packet writing 是一种协议，可用于对可记录的光学媒体（optical media 年轻的读者可以跟他们的父母请教了解一下光学媒体；它曾经很重要）进行写入。内核在 2004 年底开始支持 packet writing。然而，截至 2016 年，pktcdvd 驱动没有得到维护，也没有人关注；常规的 block 驱动早已可以支持所有 optical device 了，而 packet-writing
驱动似乎不再有必要了。它在 4.10 版本中被标记为 deprecated，并承诺 "在一两个版本之后" 将被删除。

整整 33 个版本之后，这个驱动在 6.2 版本的合并窗口中被真正删除了。然而，这导致了 Pali Rohár 的投诉，他说：

这个 6.2-rc1 版本破坏了对 CD-RW、DVD-RW、DVD+RW 以及部分 DVD-RAM 存储设备的支持，因为在这个版本中，pktcdvd 驱动被从内核中移除掉了。这个驱动程序仍在使用，它的用户空间工具是 udftools 项目的一部分，该项目仍在积极维护中。越来越多的人最近在通知我这个 "惊喜"。

Torvalds 和 block 子系统维护者 Jens Axboe 都质疑这个驱动的必要性，但很明显它仍然提供了一些 udftools 等项目所需要的功能（尤其是确保所有写入的文件大小正好为 32KB）。所以 pktcdvd 又被加回来了。有一些人在讨论把必要的逻辑放到 SCSI CD 驱动中，但是，正如 Torvalds 所指出的，"没有人会有动力在这个领域做任何开发工作，我们能做的最好的事情可能就是让它继续跛着脚前行吧"。如果在某个时候，这个驱动程序不能正常工作了，开发者可能会开始考虑再次把它删除掉。

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

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

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