LWN：kernel 未来如何对待32-bit支持？

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

The future of 32-bit support in the kernel

By Jonathan Corbet
September 1, 2025
OSS EU
Gemini flash translation
https://lwn.net/Articles/1035727/

Arnd Bergmann 在 2025 年欧洲开源峰会 的演讲一开始就明确表态：32 位系统在任何新型产品中的应用都已过时。目前继续使用它们的唯一原因是为了支持现有的硬件和软件。鉴于 Bergmann 是内核架构支持的整体维护者，他经常被问及是否可以移除对 32 位系统的支持。因此，他总结道，现在是时候更多地讨论这种可能性了。

他接着说，人们自然首先想到桌面计算机。如果你在 1990 年代运行 Linux，你使用的是 32 位的桌面系统。然而，Unix 系统大约 30 年前就转向了 64 位平台，而 Linux 桌面大约 20 年前也完成了这一转变。甚至手机及相关设备在过去十年中也已全部采用 64 位。如果 Linux 只需要支持这些系统，那么对 32 位的支持早就从内核中移除了。他用这张幻灯片总结了情况，展示了非嵌入式架构 (non-embedded architectures) 随着时间的推移，如何转向 64 位或不复存在：

然而，世界并非只有桌面——或服务器；嵌入式 Linux (embedded Linux) 也同样存在。这些系统中约 90% 运行在 Arm 处理器上。多年来，内核积累了大量描述这些系统的设备树文件 (devicetree files)；直到去年，armv8 (64 位) 系统的设备树数量才超过了 armv7 (32 位) 系统。

对于采用 pre-armv7 (Armv7 之前) 架构的 Arm 处理器，目前只有三种仍然可以买到硬件，但内核社区 (kernel community) 仍然支持其中的一些：

许多其他 pre-armv7 CPU 已经停产，但内核仍对其提供支持。他说，其中大约有十种现在就可以移除支持。能够说对其他处理器的支持将在固定期限（比如十年）后移除会很好，但硬件支持并非如此运作。相反，人们必须从“半衰期”的角度来思考；每隔一段时间，就有可能移除对一半平台的支持。这一切都取决于相关处理器是否有用户。

他说，内核仍在为一些 32 位开发板添加支持，但每增加一个 32 位开发板，至少会有十个新的 64 位开发板获得支持。

内核中仍然支持一些非 Arm 的 32 位架构；其中包括 arc、microblaze、nios2、openrisc、rv32、sparc/leon 和 xtensa。在新的产品中，它们都被 RISC-V 处理器所取代。他说，如果你不关心 Arm 兼容性，那么 RISC-V 就是你的选择。

此外，还有一个蒙尘的角落，那里是 nommu (无内存管理单元处理器) 的栖息地；其中包括 armv7-m、m68k、superh 和 xtensa。现在没有人使用这种硬件来构建任何东西，唯一还在以任何方式使用它们的人，是为了支持现有系统。“或者只是为了证明它可行。”

仍然有一些人需要运行无法更新的 32 位应用程序；他一直向人们推荐的解决方案是在 64 位内核上运行 32 位用户空间 (user space)。对于内存受限系统来说，这是一个很好的解决方案；切换到 32 位可以将系统内存使用量减半。由于在大多数系统中，几乎所有内存都由用户空间使用，因此运行 64 位内核的开销相对较小。他请求大家，不要在 64 位处理器上运行 32 位内核。

维护 32 位支持确实会带来一些明确的痛点；他说，大多数抱怨来自内存管理子系统 (memory-management subsystem) 的开发者。最大的问题是需要支持高端内存 (high memory)；它很复杂，并且需要整个内核的支持。当内核缺乏地址空间来映射所有已安装的物理内存时，就需要 high memory；在 32 位系统上，这通常发生在约 800MB 处。（有关 high memory 的更多信息，请参阅这篇文章）。

目前，内核能够支持安装高达 16GB 内存的 32 位系统。然而，这样的系统极其罕见，对它们的支持很快就会被移除。市面上有一些 4GB 系统，包括一些 Chromebook。2GB 系统则更为常见。他说，即使是这些系统也“有点傻”，因为内存的成本甚至超过了 CPU。不过，这些系统也有一些用例。目前大多数 32 位系统安装的内存都少于 1GB。内核很快将不再尝试支持内存超过 4GB 的系统。

现在有一些想法，旨在无需高端内存抽象 (high-memory abstraction) 即可支持内存更大的 32 位系统。Linus Walleij 正在致力于完全分离内核和用户空间地址空间 (user-space address spaces)，使每个空间都有 4GB 可用；这是“4G/4G”方法的变体，这种方法多年来偶尔被尝试。Bergmann 表示，很难让这样的系统高效运行，所以这项努力可能永远不会成功。

另一种方法是提议的 “densemem (密集内存)” 内存模型，它通过一些巧妙的重映射来填补物理地址空间中的空洞。Densemem 可以支持高达 2GB 内存，并且需要替换 SPARSEMEM (稀疏内存) 内存模型，后者无论如何最终都将被移除。这项工作必须在 high memory 被移除之前完成；Bergmann 表示他很乐意听取 densemem 方法的潜在用户 (potential users) 的意见。

另一种可能性是放弃 high memory，但允许将额外的物理内存用作 zram 交换设备 (zram swap device)。虽然这不如直接访问内存高效，但它相对简单，并且可以消除 high memory 的复杂性。

然后是 2038 年问题，他为此花费了数年时间。内核方面的工作于 2020 年完成；musl C 库也在同年更新，GNU C 库则在次年跟进。一些发行版维护者比其他公司更快地整合了这项工作；Debian 和 Ubuntu 今年才成为 2038 年问题安全 (year-2038-safe)。

然而，2038 年问题尚未完全解决；许多软件包在这个领域存在未修复的错误。他说，任何使用 futex() 的东西，大约有 50% 的机会能正确处理时间。不符合 2038 年问题安全的传统 32 位系统调用仍可在内核中启用，但它们将在某个时候被移除，从而暴露更多错误。有些语言，包括 Python 和 Rust，存在大量损坏的语言绑定。总的来说，他说，他预计任何 32 位桌面系统都无法在 2038 年末日中幸存。

一个相关的问题是大端序 (big-endian) 支持，它也仅限于 32 位，并且也已过时。它的移除受到了阻碍，因为 IBM 仍在支持大端序大型机和 PowerPC 系统；只要这种支持继续存在，大端序支持就会留在内核中。

许多其他类型的支持正在讨论中。过去曾有超过八个 CPU 的 32 位系统，但现在没有人再使用这些机器了，因此可以移除其支持。对 armv4 处理器（例如 DEC StrongARM CPU）的支持应该被移除。对早期 armv6 CPU（包括 omap2 和 i.mx31）的支持“使一切变得复杂”；他希望移除它，即使现在仍有一些 诺基亚 770 系统在市面流通。移除所有非设备树主板文件 (non-devicetree board files) 的时机也即将到来。对 Cortex M CPU（属于 nommu (无内存管理单元) 系统）的支持将在几年内被移除。开发者们正在关注 i486 CPU 支持，但这还不会立即实现。Bergmann 已发送补丁以移除对 32 位 CPU 上的 KVM (Kernel-based Virtual Machine) 支持，但仍有“一个 PowerPC 用户”，因此该支持目前将保留。

他总结道，内核将不得不至少再保留对 armv7 系统的支持十年。这些 CPU 的开发板仍在生产中，所以即使是十年对于移除来说也可能过于乐观。他说，其他的一切可能都会比这更快地消失。移除高端内存支持已暂定在 2027 年左右，而 nommu 支持则在 2028 年左右。当然，在这些移除发生之前，还需要进行更多讨论。

一位听众提问，开发者如何知道一个处理器是否仍在被使用；Bergmann 承认这是一个难题。对于 x86 支持，他查看了大量旧网页，列出了哪些系统存在，然后指出这些系统中的每一个都因其他原因而在当前内核中已经无法正常工作；没有收到投诉表明没有用户。对于其他处理器，则需要深入研究 Git 历史记录，查看正在进行哪些类型的更改，并询问曾参与代码工作的开发者；他们是唯一知道谁在使用该支持的人。

另一个人询问内核是否会支持大端序 RISC-V 系统。Bergmann 回答说这些系统目前不受支持，他希望这种情况能继续保持。“对于 RISC-V，任何人都可以做任何事，所以他们确实在做，但这并非总是好主意。”最后一个问题是关于对 nommu esp32 CPU 的支持；他回答说这些 CPU 的补丁是存在的，但尚未提交到上游 (upstream)。他说这些处理器是“很酷的玩具”，但他没有看到它们有任何实际应用。

本次演讲的幻灯片 可供查阅。感兴趣的读者也可以回顾 Bergmann 在 2020 年对这个话题的看法。

[感谢 Linux 基金会，LWN 的差旅赞助商，支持我参加此次活动。]

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

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

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