LWN：内核处理Rust代码的流程！

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

A process for handling Rust code in the core kernel

By Jonathan Corbet
March 27, 2025
LSFMM+BPF
Gemini-1.5-flash translation
https://lwn.net/Articles/1015409/

2024 年的 Linux 存储、文件系统、内存管理和 BPF 峰会包括 一次气氛紧张的会议，讨论了在内核文件系统层中使用 Rust 代码的问题。2025 年，Rust 话题再次出现，由 Andreas Hindborg 主持会议，范围也涵盖了存储和内存管理层。已经取得了很大进展，今年的讨论对抗性有所减少，但仍有一些流程问题需要解决。

如何将 Rust 代码提交到上游

Hindborg 首先指出，Rust 代码进入内核有多种途径，他将这些途径按照“Brauner-Hellwig 量表”进行排列。在 Brauner 一端，一些子系统直接接受 Rust 代码并自行维护；虚拟文件系统层（virtual filesystem layer，由 Christian Brauner 共同维护）就是一个例子。在这些子系统中，Rust 补丁就像其他任何补丁一样被接受。

沿着量表往下看，一些子系统的开发者希望能够直接接受 Rust 代码，但维护者承认他们需要帮助才能做到这一点。内核的模块加载器（module loader）就是一个例子；为了合并这些代码，Rust 社区的专家一直在提供帮助。其他子系统指定一个单独的子维护者来处理 Rust 代码；块层（block layer）被提及使用了这种模式。

然后，还有一些子系统根本不处理 Rust 代码；对于这些子系统，代码会通过 Rust 树（Rust trees）提交。在某些情况下，维护者是愿意的，并且会充当审查者，但不认为他们可以直接处理这些代码；时间管理（timekeeping）在这里被提及。最后，有些子系统根本不与 Rust 开发者合作；他们只是不想了解 Rust 代码。DMA 映射（DMA-mapping） 和 XArray 子系统就是这种情况。

Hindborg 说，这些模式都没有错，但最后一种效率最低。一个子系统的 C 语言维护者最了解该子系统，因此需要他们的投入才能获得最佳结果。他说，理解 Rust 并不是审查提交内容的必要条件；Rust 代码有大量的文档记录，对代码预期语义的注释是最重要的。

Ted Ts'o 说，如果能对测试和破坏（breakage）设定更明确的预期，那将会有所帮助。如果 Rust 代码要通过常规的子系统树（subsystem trees），那么维护者至少应该对这些代码进行构建测试（build tests），并且应该有一个明确的方案来应对构建出错（build break）的情况。如果树（tree）无法构建，他问道，是否应该在一段时间后直接删除补丁？Hindborg 回答说，如果在合并之前观察到中断，那么应该立即删除补丁。但他说，通常情况下，当发生中断时，人们会直接修复它并继续前进。

David Hildenbrand 指出，更改 C 接口可能会需要更改大量的 Rust 代码才能匹配。如果 Rust 代码没有在同一个树（tree）中维护，那么不清楚应该如何拆分补丁。Hindborg 说，这样的补丁可以像任何树范围（tree-wide）的系列补丁一样处理。如果需要，开发者可以创建一个新的 API 并缓慢地将代码转换到该 API。如果开发者在更改 Rust 代码时遇到问题，他们可以寻求帮助。

Liam Howlett 说，如果他合并了一个破坏 Rust 代码的更改，那么会立即导致问题，例如破坏持续集成（continuous-integration）构建。然后，指责的矛头会指向他。能够一起完成所有这些更改将非常重要。Hindborg 同意，但他也指出，在块（block）子系统中，开发者进行更改时并不担心 Rust 方面的问题。当他收到问题报告时，他会在一天内修复它，一切都会很好。Howlett 回答说，这种方法是不可扩展的；更多使用 Rust 的子系统会导致更多麻烦。Hindborg 同意，最好能在一个系列中完成所有的更改，但他不认为他可以要求开发社区这样做 —— 或者即使他提出了要求，也无法得到满足。Petr Tesařík 指出，破坏 Rust 代码可能会给试图进行回归分析（bisect regressions）的开发者带来麻烦。

Hindborg 询问块（block）子系统维护者 Jens Axboe 接受 Rust 代码的经验；Axboe 回答说，这几乎没有增加任何开销。他说，如果有什么东西坏了，他经常会在甚至意识到问题之前就收到修复该问题的补丁。一切都运行良好，但他指出，块（block）子系统目前还没有大量的 Rust 代码。当 Hindborg 询问时，Axboe 说他确实启用了 Rust 进行构建，但无法运行测试所有内容。

Ts'o 说，直到最近他才进行启用 Rust 的构建，而且仍然没有定期进行。原因是他的测试基础设施（test infrastructure）是基于 Debian stable 的，而该发行版没有足够新版本的 Rust 编译器。他已经使用 Debian testing 使其正常工作，但运行该发行版会带来其他问题。Hindborg 说，这是一个容易解决的问题，只需要等待。最低版本的 Rust 在一段时间内一直是 1.78.0；随着时间的推移，这些问题将会消失。

Matthew Wilcox 说，他的系统上没有最新的 Rust，因为他不喜欢当系统管理员。他把这项工作留给发行商；在发行商提供合适的编译器之前，他就不会使用它。Jason Gunthorpe 说，他曾尝试在 Ubuntu LTS 上进行 Rust 构建，但 内核文档 中的说明在那里不起作用；Hindborg 说他会确保修复它。

当前和未来状态

Hindborg 说，一组用于 configfs 文件系统的抽象已经准备好供考虑，但是 configfs 的维护团队最近被“削减了一半”（在 Christoph Hellwig 停止做这项工作之后）。只有一位维护者，而且不回复电子邮件。事实证明，列出的维护者已经退休；Hindborg 被建议将他从维护者条目中删除，并接管该子系统。

Hindborg 说，最近取得了很多进展。“rnull stub”（一个块 null 设备驱动程序）已经合并，他说，32 位 x86 系统的 Rust 支持也已经合并。现在可以从 kernel.org 下载 Rust 工具链。其他合并的代码包括用户空间访问模块（user-space access module）， struct page 、 struct file 和 struct cred 的抽象，以及一个链表实现（linked-list implementation）。渲染后的内部文档 可以在 kernel.org 上找到。

第一个用 Rust 编写的“真正的”驱动程序，用于 Applied Micro QT2025 PHY 设备，已经合并。KASAN 清理器（KASAN sanitizer）和 Clang 控制流完整性（Clang control-flow integrity）都可以与 Rust 代码一起工作。还有一个用于 misc 设备的抽象，对跟踪点（tracepoints）和 RCU 读取锁定的支持。他说，内存管理抽象的添加也大大改进了虚拟内存区域（virtual memory area，VMA）锁定文档。

展望未来，Hindborg 说，有争议的 DMA 映射抽象（DMA-mapping abstractions）即将到来 [当您阅读本文时，可能已经发生了]。将会有对高分辨率定时器（high-resolution timers）、模块参数（module parameters）、I/O 轮询（I/O polling）、XArray 数据结构、 iov_iter 机制和 VMA 的支持。从长远来看，Nova 图形驱动程序正在向前发展；这将是一项为期多年的工作。

在他的结论中，他重申，自 6.10 版本以来，Rust 编译器的最低版本一直保持在 1.78.0，即使较新的版本已经获得了支持。他说，目前内核只需要四个不稳定的功能，而且这个数字很快就会变为零。编译器团队在其持续集成测试中包含了内核构建，以确保它们不会破坏它。他说，内核是 Rust 项目的“旗舰目标”；Rust 开发者认真对待内核项目，希望它能正常工作，并为此投入资源。

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

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

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