LWN：内核维护者们对Rust-for-Linux的观点！-优快云博客

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

Maintainer opinions on Rust-for-Linux

By Daroc Alden
February 10, 2025
FOSDEM
Gemini-1.5-flash translation
https://lwn.net/Articles/1007921/

Miguel Ojeda 在FOSDEM 2025 大会上的一次主题演讲中，介绍了 Rust-for-Linux 项目的历史，以及内核社区目前对该实验的态度。与他以往的演讲不同，这次演讲并没有过多关注项目的现状，而是侧重于讨论历史和对未来的预测。他最终展示了 30 多位参与内核开发的开发者所提供的对该项目的看法和未来期望。

背景信息

Ojeda 首先为那些可能不熟悉 Rust-for-Linux 的听众介绍了该项目，将其定义为尝试在 Linux 内核中增加对 Rust 语言的支持。他说，该项目不仅仅是将 Rust 添加到驱动程序中，更在于最终在内核核心中实现对该语言的一流支持。长期目标是让内核维护者能够在 C 和 Rust 之间自由选择。

尽管这项任务非常艰巨，但已经有很多人在正在开发的 Rust 绑定之上构建驱动程序。Ojeda 花了一些时间来讨论为什么会这样。Linux 内核已经具有可扩展性，引入一种新语言的成本非常高 — 那么，为什么人们要付出这么大的努力，仅仅为了能够用 Rust 编写驱动程序呢？

在回答这个问题时，Ojeda 表示，他想给出一个比通常用“内存安全”来解释更令人满意的答案。他展示了一段 C 语言的示例代码，询问该函数是否实现了注释中的描述：

/// Returns whether the integer pointed by `a`/// is equal to the integer pointed by `b`.bool f(int *a, int *b) {    return *a == 42;}

在场的开发者们都相当肯定，所展示的代码实际上并没有遵循注释。Ojeda 展示了显而易见的修正版本，然后展示了用 Rust 编写的等效代码：

// Corrected Cbool f(int *a, int *b) {    return *a == *b;}

// Equivalent Rust versions before and after being fixedfn f(a: &i32, b: &i32) -> bool {    *a == 42}fn f(a: &i32, b: &i32) -> bool {    *a == *b}

这些 Rust 函数与 C 函数几乎相同。事实上，它们编译成完全相同的机器代码。除了函数声明的拼写方式之外，C 和 Rust 在这里没有明显的区别。而且这两种语言都不能帮助程序员发现注释和函数行为之间的不匹配。那么，为什么有人想编写后者而不是前者呢？

Ojeda 的答案是：信心。作为一名维护者，当有人发送补丁时，他可能会或可能不会发现它是 broken 的。在像这样明显的例子中，希望他能发现。但更微妙的逻辑错误可能会而且确实会溜过去。逻辑错误很糟糕，但内核的崩溃（或 compromise）更糟糕。对于 C 版本，某些其他代码可能依赖于此函数按照文档中的描述运行，以避免覆盖内存的某些部分。Rust 版本也是如此。对于审阅者来说，区别在于 Rust 将事物分为“safe”和“unsafe”函数 — 审阅者可以专注于不安全的部分，将他们有限的时间和注意力集中在可能产生广泛影响的部分。如果一个安全函数使用了不正确的 f , 它仍然可能是错误的，但不会崩溃。这让审阅者对他们的审阅更有信心。

Ojeda "希望这个非常简单的例子能激起你的好奇心，如果你是一名 C 开发者"，但它也解释了为什么人们想要用 Rust 编写内核组件。内核编程已经很复杂了；稍微更有把握地确保你不会完全破坏整个内核是有价值的。

最初的 Rust-for-Linux RFC (Request for Comments, 意见征求稿) 中列出的目标确实包括其他要点，例如希望 Rust 代码能够减少逻辑错误并简化重构。但该项目愿景的核心部分一直是让更多人更容易地为内核做贡献，从而帮助那些原本觉得不舒服的人参与到内核开发中来。

历史

在建立了上述背景之后，Ojeda 接着介绍了 Rust-for-Linux 项目的历史。实际上，将 Rust 与 Linux 内核结合使用的想法已经有十多年了。最早的例子是 rust.ko , 这是一个简单的概念验证，写于 2013 年，甚至在 Rust 于 2015 年达到 1.0 版本之前。实际的代码将成为 Rust-for-Linux 项目的基础，linux-kernel-module-rust , 创建于 2018 年，并在树外维护了数年。

Ojeda 在 2019 年创建了 Rust-for-Linux GitHub 组织，但直到 2020 年该项目才真正启动。在那一年的 Linux Plumbers Conference 期间，许多人就该项目进行了一次合作演讲。当时这还是“一个白日梦”，但有足够多的人感兴趣，该项目开始受到关注，并且有许多人加入了。

在 2020 年底和 2021 年初，贡献者们为树内 Rust 编写了第一个补丁集 , 设置了邮件列表和 Zulip 聊天实例 , 并将 Rust 基础设施合并到 linux-next 中。2021 年还通过 LWN 的 BigBlueButton 实例运行了第一个 Kangrejos ，即 Rust-for-Linux 会议。2022 年，Rust-for-Linux 补丁集从第 5 版升级到第 10 版，最终被合并，赶上了 Linux 6.1 长期支持版本。

从那时起，该项目（一直与上游 Rust 项目合作）开始与 Rust 语言开发者更紧密地合作。该项目获得了更多的基础设施，包括一个网站，并自动渲染内核文档。一些贡献者还开始扩展最初的 Rust 绑定。Ojeda 特别提到了 Boqun Feng、Wedson Almeida Filho、Björn Roy Baron、Gary Guo、Benno Lossin、Andreas Hindborg、Alice Ryhl、Trevor Gross 和 Danilo Krummrich 的工作，并将他们的贡献放在时间轴上，以突出该项目随时间的增长。

未来

Ojeda 在演讲结束时，展示了一系列他从许多不同的内核开发者和与 Linux 社区相关的人那里征集来的引言，内容是他们对该项目未来的看法。人们通常会根据引起最多讨论的内容来形成对社区对某个主题的印象 — 这会放大有争议的观点。为了清楚地了解现有内核维护者对 Rust-for-Linux 实验的看法，Ojeda 联系了许多参与讨论该项目的人 — 无论是作为支持者还是反对者。引言的数量远远超过他在剩余时间内可以讲完的，但他确实重点介绍了一些特别重要或有见地的引言。感兴趣的读者可以在他的幻灯片中找到完整的引言列表。

Daniel Almeida 向内核贡献了多个补丁，特别是在为 Rust 中的 GPU 驱动程序奠定基础方面，他说：

2025 年将是 Rust GPU 驱动程序的一年。我相信一旦主要的抽象概念到位，将会取得很多成就，到目前为止，进展一直很稳定，来自多家公司的工程师共同努力解决每个难题。DRM 维护者也很 receptive ，因为他们看到 Rust 和 C 可以共存的清晰路径，而不会破坏他们已建立的维护流程。事实上，考虑到维护者、公司和工程师的所有 buy-in ，我想说 Rust 肯定会留在这个内核部分。

Ojeda 同意 Almeida 的预测，他说他预计 2025 年也将是 Rust 在图形子系统中的重要一年。许多 Rust-for-Linux 贡献者（不出所料）也对该项目的未来持乐观态度。即使是那些对该语言不太热衷的人，通常也同意它将成为内核中越来越重要的一部分。Steven Rostedt 是一位内核维护者，在内核的多个部分都有贡献，他认为这种语言对于其他内核贡献者来说很难学习：

它需要不同的思维方式，并且某些语法有点违反直觉。尤其是“！”对宏的使用，但过了一段时间后我就习惯了。

尽管如此，他认为内核中的 Rust 可能会继续增长。Rostedt 说，即使 Rust 最终被用于内核编程的更安全的 C 子集所取代，Rust 仍然会提供推动朝这个方向发展的动力。Wolfram Sang 维护着许多 I2C 驱动程序（Rust-for-Linux 项目希望扩展到的一个领域），他也对学习 Rust 的难度表示担忧：

我真的很乐于包含 Rust 并尝试它带来的好处。但就我个人而言，我没有带宽去学习它，也没有客户会为我学习它而付费。我观看了一些关于 Linux 中 Rust 的高级演讲，并且对此持积极态度。但我仍然没有使用该语言的经验。

这让他对审查 Rust 代码感到担忧，他说他“根本无法审查用 Rust 编写的驱动程序”。他要求能够做到这一点的人提供帮助，并希望在此过程中逐步学习 Rust 。

Luis Chamberlain 维护着内核的可加载模块支持，他认为采用 Rust 仍然存在一些 blocking 的要求，但他很想看到这些要求得到解决：

我还不能编写任何 Rust 程序，但我会考虑将其用于内核的任何新的和严肃的事情，前提是我们获得 gcc 的支持。我最近了解到，例如，我们可以在内核中利用 Coccinelle 规则来管理 API 的方式，对于 Rust 来说是不需要的 — 遵循 API 的规则是由编译器为我们提供的。

虽然温和的保留和谨慎的乐观是 Ojeda 征求意见的常见回应，但也有一些受访者的态度不太克制。Josef Bacik 是 Btrfs 和块设备 I/O 控制器的维护者，他说：

在过去的 3 个月里，我一直在专门使用 Rust 工作，我再也不想回到基于 C 的开发了。

Rust 使我在编写 C 时考虑的很多事情都变得无关紧要。我花更少的时间处理愚蠢的错误，我只需要让它编译即可。

[…]

我希望 Rust 在 Linux 内核中更加成功，它最终会的。不幸的是，我没有耐心等待那么久，我将从事其他可以使用 Rust 的项目。我认为 Rust 会使整个系统变得更好，并有望吸引更多的开发人员。

Ojeda 收集的引言表达了许多关于 Rust-for-Linux 项目未来的深思熟虑、细致入微的观点。简单概括一下：大多数回应认为在 Linux 内核中包含 Rust 是一件好事；/绝大多数/ 人认为这在目前是不可避免的，无论他们是否赞同。被引用的主要剩余障碍是学习 Rust 的难度，这可能很难改变，以及 GCC 支持，这已经进行了一段时间。

做出回应的内核开发者还认为，即使 Rust-for-Linux 显然在增长，但仍有大量工作要做。总的来说，人们的期望似乎是，还需要几年的努力才能解决 Rust 集成方面的所有当前问题，但人们愿意 — 或者至少容忍 — 看到这项工作完成。

[虽然 LWN 今年无法亲自参加 FOSDEM , 并且 Ojeda 演讲的视频尚未发布，但我确实观看了演讲的直播，以便能够对其进行报道。]

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

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

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