LWN：企业内核使用Rust！

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

On Rust in enterprise kernels

By Jonathan Corbet
October 10, 2024
Gemini-1.5-flash translation
https://lwn.net/Articles/993337/

在最近结束的维护者峰会上，大家普遍同意 Rust 实验将继续进行，并且路线已经明确，可以将更多 Rust 代码引入内核。但是，在这种会议上形成的高层观点并不总是能够考虑到随着 Rust 工作的推进，不可避免地会出现的一些棘手的细节问题。最近在 nouveau 邮件列表上的一次讨论可能没有引起很多人的注意，但是它突出了一些问题，这些问题将会随着用 Rust 编写的、具有重要功能的代码进入主线（mainline）而必须得到解决。

参与者

首先介绍一些背景：nouveau 驱动程序 用于处理 NVIDIA GPU。多年来，在没有任何 NVIDIA 帮助的情况下，它是开发者们坚定不移地进行逆向工程的成果；在 2009 年发布的 2.6.33 版本中，它被 首次合并到主线。最近，NVIDIA 改变了对自由软件支持其产品的态度，并一直在帮助 nouveau 的开发。多年来一直致力于 nouveau 开发的 Ben Skeggs，最近在那里找到了工作。

Nouveau 已经达到了合理的功能水平，但是内核 DRM（图形）子系统中的开发人员已经在考虑替换它，至少对于较新的 GPU 是这样。具体来说，Nova 项目 已经启动，旨在为未来的 NVIDIA GPU 创建新的驱动程序。与 nouveau 不同，Nova 将使用 Rust 编写。参与开发的程序员认为，使用 Rust 是处理较新 GPU 中固件接口的最佳方式，因为这些接口可能随时发生变化，而不会发出通知。Nova 是一个相对年轻的项目，可能在几年内都无法做好进入主线的准备。

内核中一个完全不同的部分是 虚拟功能 I/O (VFIO) 子系统。简而言之，VFIO 是一个用于控制 I/O 内存管理单元（IOMMU）的接口，它可以用来安全地将对设备的访问权限授予用户空间进程。IOMMU 将确保设备只能访问属于使用它的进程的内存，从而防止设备（意外地或故意地）覆盖系统的其他部分。VFIO 通常用于运行虚拟化客户机的系统中；每个客户机都可以访问其所需的设备，同时保持整个系统的安全。

为了完成对角色的介绍：9 月下旬，Zhi Wang 发布了 一个包含 23 个补丁的补丁集，为 NVIDIA GPU 实现了新的“vGPU”功能。市场对基于云的、具有 GPU 访问权限的系统的需求正在不断增长，以便我们都能享受大型语言模型带来的好处，这些模型会不请自来地出现在我们生活的方方面面。vGPU 补丁使云提供商能够轻松地为虚拟机提供对一个或多个 GPU 的访问，并在发生争用时对这些 GPU 的使用进行仲裁。NVIDIA 显然认为（可能是有充分理由的），这项功能将使其 GPU 对云提供商更具吸引力，因为众所周知，云提供商会购买数量可观的硬件。为了配合 NVIDIA 对上游更加友好的态度，所有这些工作都针对主线内核。

反向移植的担忧

正如人们所预料的那样，这个新的子系统是基于 VFIO 的，这意味着内核已经为虚拟化设备控制导出的接口将可以与 NVIDIA GPU 一起工作。这个决定是没有争议的。但是，vGPU 的工作也依赖于 nouveau 驱动程序来访问硬件，并且对 nouveau 进行了重大的更改以添加它所需的支持。这方面引起了 Nova 背后的开发人员的注意，他们担心将此功能建立在一个他们正在努力替换的驱动程序之上。计划是由 Nova 来驱动由 vGPU 管理的芯片组，因此自然希望看到所有这些工作都在 Nova 中完成。

Danilo Krummrich 询问 vGPU 的长期策略是什么：""这更像是一个概念验证吗？您是否计划在 Nova 上进行一般性的工作以及对 Nova 的 vGPU 支持？"" 看起来参与了新子系统设计的 Jason Gunthorpe 回答 说，它 ""旨在成为一个客户会使用的真实产品，而不是一个概念验证""。他说，他希望看到它很快被合并。最后他说：""作为一种商业产品，这将被广泛地反向移植到许多旧的内核中，如果它不是完全用 C 语言编写的，那将更加困难/不可能。""

换句话说，新的 vGPU 子系统将由发行版（以及大型用户）反向移植到“企业”内核中，这些内核的核心早于 Rust 支持被引入主线；Gunthorpe 估计 只有 10% 运行在目标系统上的内核是基于 6.0 或更新的版本。由于最初的 Rust 支持是在 6.1 版本中才加入的，而且即使是现在也还远未完成，任何对 Rust 的依赖都将明显增加反向移植 vGPU 的难度，如果真的可以做到的话。结果可能是 vGPU 子系统根本无法进入那些旧的内核，这对许多相关的人（和公司）来说将是一个令人失望的结果。因此，Gunthorpe 的结论是，vGPU 目前必须继续基于 nouveau，而 Nova 项目必须设法与之共存。

Krummrich 承认 目前使用 nouveau 是一种合理的方法，但他担心 Nova 的加入会导致内核内部的功能重复。他说，为了避免这种情况，需要达成一项协议，即从长远来看，vGPU 开发人员将承诺帮助 Nova 的开发以及将 vGPU 迁移到 Nova 基础之上的工作。Gunthorpe 同意 Nova 将来有一天可能会成为 vGPU 的基础，但他指出，虽然 vGPU 是一个可以正常工作的驱动程序，可能很快就会被合并，但 Nova 还不存在；""我们先别想得太远""。

分歧和选择

随之而来的是一场偶尔激烈的讨论，参与者似乎并不总是能理解彼此。Gunthorpe 建议创建一个只包含必要功能的核心驱动程序（用 C 语言编写），以便更高级别的驱动程序能够与设备通信；nouveau 和 Nova 都可以位于该核心驱动程序之上。然而，DRM 维护者 Dave Airlie 坚持认为最底层必须使用 Rust：

核心必须是 Rust，因为 NVIDIA 的固件 API 不稳定。这种不稳定的固件 API 不仅仅是命令封送，而是深入其内部，如内存大小要求、基本消息队列布局和编码、固件初始化过程。这些都可能随时发生变化，而不考虑上游开发，因此上游开发需要尽可能地与这些变化隔离。使用 Rust 提供了隔离层。

他建议，可以采用一些方法来规划过渡，使 VFIO 方面的工作尽可能轻松。Gunthorpe 回答说：“我们现在不能在 VFIO 中使用 Rust，我们没有这种奢侈。这就是事实，我无法改变它。”他还说，如果“可以证明反向移植问题能够得到解决”，他对在 VFIO 中使用 Rust 的反对意见会有所减少。他说，也许可以编写一个最小的 Rust 核心驱动程序来替代 C 版本，并以此来了解反向移植问题的实际难度。

关于反向移植，Greg Kroah-Hartman 建议 Gunthorpe “永远不要基于与当今上游内核开发无关的古老商业内核做出设计决策”。他说，如果企业有兴趣在企业版内核中获得 vGPU 支持，他们应该为将必要的补丁反向移植到这些内核中付费。Gunthorpe 回复说，在内核社区认定对 Rust 的支持不再是实验性的之前，他不准备接受任何此类依赖。他还表示希望这个问题能够自行消失：

现在讨论这个 *为时过早*。我衷心希望我们永远不必真正面对它，希望到 Nova 合并时，Rust 已经 100% 为上游做好准备，并且不会有任何问题。可以吗？这有可能发生吗？

谈话最终不了了之。短期内，没有任何需要做出的决定；在当前的主线内核中，vGPU 能够工作的唯一方法是使用 nouveau，因此如果它没有以这种形式被合并，那将是令人惊讶的。即使是 Nova 的开发者也没有对此提出异议。从长远来看，幸运的话，事情会如 Gunthorpe 所希望的那样发展，当 Nova 准备好进入上游时，那里的行动方针也会很明确。

也许生活不会那么轻松，但无论如何我们有理由保持乐观。虽然双方的立场似乎都很绝对，但所有参与的开发者都表示有兴趣找到对每个人都有效的解决方案。对于社区正在努力实现的长期目标，并没有分歧，我们有理由相信，将会找到一个关于如何实现目标的协议。

然而，这次讨论中出现的一些主题可能会再次出现。任何依赖于 Rust 代码的功能都将给反向移植到古老的企业版内核带来挑战，因此合并这些代码可能会招致反对，即使是总体上支持 Rust 的开发者也会反对。在某种程度上，如果 Rust 项目要取得成功，内核将不得不迈出这一步。不过，预计还会有一些关于何时应该达到这一点的进一步讨论。

The core has to be rust, because NVIDIA has an unstable firmware API. The unstable firmware API isn't some command marshalling, it's deep down into the depths of it, like memory sizing requirements, base message queue layout and encoding, firmware init procedures. These are all changeable at any time with no regard for upstream development, so upstream development needs to be insulated from these as much as possible. Using rust provides that insulation layer.

他建议可以有一些方法来计划过渡，使 VFIO 方面的工作尽可能轻松。Gunthorpe 回答 说：""我们现在不能在 VFIO 中使用 Rust，我们没有这种奢侈。这是一个事实，我无法改变它。"" 他还说，如果 ""能够证明反向移植问题已经得到解决""，他对在 VFIO 中使用 Rust 的反对意见会减少一些。他说，也许可以编写一个用 Rust 编写的最小核心驱动程序来替代 C 版本，并用它来观察反向移植问题到底有多难。

关于反向移植，Greg Kroah-Hartman 建议 Gunthorpe ""永远不要根据与当今上游内核开发无关的、古老的商业内核做出设计决定""。他说，如果公司有兴趣在企业内核中获得 vGPU 支持，他们应该付费将必要的补丁反向移植到这些内核中。Gunthorpe 回答 说，在内核社区决定 Rust 支持不再是实验性的之前，他不准备接受任何此类依赖。他还表示，希望这个问题能够自行消失：

This argument is *way too early*. I'm deeply hoping we never have to actually have it, that by the time Nova gets merged Rust will be 100% ready upstream and there will be no issue. Please? Can that happen?

这场对话最终不了了之。短期内，不需要做出任何决定；对于当前的主线内核来说，让 vGPU 工作的唯一方法是使用 nouveau，因此如果它没有以这种形式被合并，那将是非常令人惊讶的。即使是 Nova 的开发人员也没有对此提出异议。从长远来看，幸运的话，事情会像 Gunthorpe 希望的那样发展，当 Nova 准备好进入上游时，那里的行动方针也将是明确的。

也许生活不会那么轻松，但无论如何，我们有理由保持乐观。虽然双方的立场似乎都很绝对，但所有参与的开发人员都表示有兴趣找到对每个人都有效的解决方案。对于社区正在努力实现的长期目标，并没有分歧，而且我们有理由相信，将会就如何实现这些目标达成一致。

不过，这次讨论中出现的一些主题可能会再次出现。/任何/ 依赖于 Rust 代码的功能都很难反向移植到古老的企业内核中，因此合并这些代码可能会招致反对，即使是总体上支持 Rust 的开发人员也会反对。在某个时候，如果 Rust 项目想要取得成功，内核将不得不迈出这一步。不过，预计还会有一些关于何时应该达到这一点的讨论。

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

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

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