最近，Rust for Linux 项目的开发者之一 Wedson Almeida Filho 辞职了。
在临别留言中，他链接了一段文件系统维护者对他大喊大叫的视频。
之后，Linux 版苹果 GPU 驱动程序（尚未上游化）的开发者 Asahi Lina 在 Mastodon 上发布了一系列帖子（第一篇），对 Wedson 表示同情，并从 DRM 的角度表达了自己对维护者和 Rust 的不满。
虽然我们很容易把这看成是 "Rust 仇恨者与 Rust 推动者 "之间的争斗，但我认为这意味着 Linux 中存在着更深层次的问题，既有技术方面的，也有文化方面的（两者往往相互影响）。
在本文中，我将为那些不熟悉的人总结一下这些问题，并推测它可能导致的后果。
Linux文档和接口
Rust 开发人员面临的最大问题之一是获取Linux接口文档。使用 C 语言编写代码时需要这些文档，但对于内核的 Rust 部分来说，这更为关键。
由于 Rust 将资源生命周期等内容编码为类型的一部分，因此了解这一点对于安全地使用接口至关重要。除了必须阅读实现或将其牢记在心之外，缺乏这些信息会损害 API、重构以及 Rust 的所有新消费者。
如果子系统维护者无法帮助解决此类问题（无论是否使用 Rust），那么就很难放心使用接口。
Linux测试与 CI
几十年来，单元测试一直是软件工程的重要组成部分。 持续集成最近开始流行，但它是测试的补充。 没有测试，你怎么知道你的更改是否仍然有效？没有持续集成，你又怎么知道是否为时已晚？ 对于更换子系统或驱动程序来说，如果你采用的是绞杀模式（strangler pattern），这一点就尤为重要。
不幸的是，内核最近才通过 kunit 等形式获得了单元测试功能。 CI 也是最近才开始出现，但在整个项目中并不一致，原因我们稍后再谈。 对于某些事情来说，这是可以理解的；如果没有硬件和观察硬件的能力，驱动程序的单元测试可能会很困难。
开发工作流程
没错，就是电子邮件。 Linux 内核邮件列表（Linux Kernel Mailing List）在基于电子邮件的开发工作流程方面是出了名的顽固派，不过也有人嘀咕过要用不同的方式来做事（子系统也有自己做事的余地）。 这确实意味着贡献工作更加困难（设置 git-send-email 是一回事，但使用它来迭代审核又是另一回事），而且如果没有工具来简化工作，事情很可能会在收件箱中消失。
总之
我认为 Rust for Linux 项目处于危险之中，这并不是因为技术原因（尽管更大的内核也无济于事），而是因为社会原因。