LWN：Rust代码审核以及netdev！

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

Rust code review and netdev

By Jake Edge
October 31, 2023
ChatGPT translation
https://lwn.net/Articles/949270/

最近有一组快速推进的 patch set（这似乎是 Linux 网络开发的常态）打算为物理层（PHY，physical layer）驱动程序添加一些 Rust 的抽象支持。人们已经进行了很多 review 工作，并且该补丁集已经在回应这些评论的过程中进行了多次重新实现。不幸的是，Rust-for-Linux的开发人员难以跟上这个速度。看起来两个社区的开发实践还是存在一些脱节。

10 月 26 日，Tomonori Fujita 发布了第 7 版补丁，其中包含使用 Rust 创建一些 PHY 驱动程序的基础设施；它还包括了一个用于Asix AX88772A PHY的驱动程序。第一个版本是在 10 月 2日发布的，并且之前有三个从 9 月 13 日开始的 RFC。在回复第 7 版的 cover letter 的时候，Rust-for-Linux 的开发人员 Miguel Ojeda 建议Fujita 放慢一些速度：

这个补丁系列在一个月内有了 8 个版本。对于这种类型的 patch set，最好拉长两次修订之间的等待时长，尤其是在先前的讨论仍在进行中、并且这是一种新的"类型"的代码的情况下。

我理解您这样做是为了让人们看到最新版本（从而关注它），这确实是有帮助的，但在先前的版本上进行讨论的时候发送版本非常快，会将讨论拆分成几个不同版本。这使得对于 review 人员来说看起来更加混乱，基本上会使人们无法跟上。

但是一直在审查这些补丁的 Andrew Lunn 指出，这种速度是 Linux 网络子系统所期望的：“[…] netdev 发展迅猛，review 意见预计在大约 3 天内会出现”。他说，应该至少在 24 小时内不要发布新版本 patch set，但快速的速度意味着更快地得出结论；“[…] 发布新版本是激励 review 者采取行动的一种方式”。但是 Rust-for-Linux 的开发人员 Boqun Feng 质疑如此频繁地发布更新补丁集是否确实达到了这个目标：“有时候看到新版本的帖子但旧的评论尚未解决，这会让 review 者感到沮丧”。

Lunn还指出，网络补丁并不需要经过审查就能合并；“如果在三天内没有反馈，并且通过了 CI [持续集成]测试，它很可能会被合并。”但是 Ojeda 表示CI 测试不足以确定这些抽象是否“设计得好或者健全，这些却是 Rust 抽象工作的关键点”（请参阅这篇文章以了解 Rust 术语中“健全（sound）”的描述）；他希望要有人类能介入。Lunn 回应说，最终是人类决定是否合并代码，但 API 问题就像其他错误一样——如果以后发现任何问题，还是可以修复的。

在该讨论的另一部分，Ojeda 描述了他看到的 netdev 社区和（新生的）Rust-for-Linux 努力的流程之间的差异。他表示，项目需要仔细审查“全新的子系统 API”，并使用一种新语言，“这是一个困难的任务”。另一个困难是 Rust-for-Linux 项目根本没有足够的审阅者和/或审阅精力来跟上 netdev 的速度。“因此，如果您需要我们的反馈，得请您耐心点。”

与此同时，他还引用了netdev文档的一些部分，指出在讨论先前版本仍在进行中时，不推荐发布新版本的代码。特别是：“在先前版本的讨论仍在进行中时，除非直接由审阅者指示，否则不要发布代码的新版本。”事实上，在内核社区的其他地方，通常不欢迎在讨论尚未平息之前发布新的补丁集。

网络子系统的维护者 Jakub Kicinski 承认了 Rust-for-Linux 项目的需求，但指出 netdev 的流程目的是能够处理大量 patch。“更长的审查周期会使跟踪补丁和讨论变得难以管理。”他想知道 Rust-for-Linux 项目在初始阶段之后是否会减少对补丁审查的参与。Ojeda 同意这是目标，但最初的抽象实现会需要更多的审查时间：

此外，对于 Rust，我们正试图使进入主线的第一个抽象尽可能设计得很好（理想情况下是“sound”），以便可以让他们作为模范例子。这需要时间，通常需要几次迭代。

他还说，还需要花时间“让人们对 Rust 代码和抽象期望的一致性达成共识”。“与代码中的设计和逻辑一样，格式也是需要解决的一部分。”他举了 Lunn 在审查中指出的问题中的一个“微不足道的例子”——最大行长度。Ojeda 表示，Rust-for-Linux 项目希望在整个内核中为其代码提供一致的格式，最好以自动化的方式维护，因此如果可能的话，这些差异需要在整个内核中解决。计划是提供一个坚实的基础，使网络开发人员“实际上能够迅速处理任何补丁，而不必等待我们”——但这需要一些时间才能实现。

Lunn 警告说，可能难以实现项目所希望的一致性——至少对于行长度而言可能如此。netdev 社区更喜欢 80 个字符的行，而其他子系统使用 100 个字符的行，并且可能不喜欢较短的行。最终来说，格式不是一个真正的技术问题，而是一个社会问题，Lunn 说：

为了使 netdev 的人满意，您将把它限制在 80。但如果另一个子系统说，与我们子系统中的 C 代码一样，代码使用 100 会更可读。我们希望 Rust 也是 100。

Linux 在子系统之间可能非常分散。这确实是现实情况，你可能必须适应。

Ojeda 似乎坚持Rust 代码将在整个内核中保持一致的格式，这与现有 C 代码的（缺乏）一致性不同。我们将在未来看到这如何演变。这次讨论突显了两个截然不同的开发社区“碰撞”时需要解决的一些问题。PHY 抽象和使用它们的驱动程序将是第一个对驱动程序编写者和普通用户都可见的 Rust 内核功能，因此开发人员想要花时间让它做得非常棒。

Linux 的开发速度远远快于大多数其他开发项目，这对内核 Rust 项目可能来说可能太快了——至少在此时是如此。另一方面，正如 Lunn 指出的，Rust API 并不是必须固定的东西；它们是内核的内部 API，因此可以像其他内核 API 一样更改。人们感觉这两个项目最终会找到一个对双方都起作用的平衡，也许在 11 月中旬即将举行的Linux Plumbers Conference上的讨论可能会有所帮助。

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

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

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