关于 Linux 内核 Rust 编程语言政策的争论仍在继续...虽然一些内核维护者对此表示反对，但据报道，Linus 表示他将无视那些可能反对采用 Rust 代码的维护者。

Linux 的二号人物 Greg Kroah-Hartman 也一直是 Rust 内核代码的强烈支持者。他近日又撰写了一篇 Linux 内核邮件列表帖子，概述了 Rust 的优势，并鼓励新的内核代码/驱动程序使用 Rust 而不是 C。

Greg KH 认为，绝大多数内核错误都是由于“C 语言中的愚蠢的小角落问题，这些在 Rust 中完全不存在”，他完全支持从 C 代码库逐步过渡到使用 Rust 的新代码，这样就可以避免这些内存安全问题和其他 C 语言缺陷。

Greg 承认 Linux 内核的 C 代码在可预见的未来不会消失，但他确实希望新的代码/驱动程序能够用 Rust 编写，以避免 C 代码中的错误和问题。

以下为 Greg 在 LKML 帖子中的完整内容，供那些对其关于内核中 Rust 代码的最新想法感兴趣的人参考。

作为过去15年（希望所有这些问题最终都会出现在稳定代码树中，有时维护者/开发者忘记将它们标记为错误修复时，我们还是会错过一些）几乎看到所有内核错误修复和安全问题的见证者，以及看到每一个内核CVE发布的人，我认为我可以就这个话题发表意见。

我们遇到的大多数bug（数量，而非质量/严重性）都是由于C语言中那些愚蠢的小角落问题造成的，这些问题在Rust中完全不存在。比如简单的内存覆盖（尽管Rust远未能够捕捉到所有这些问题），错误路径清理，忘记检查错误值，以及使用后释放的错误。这就是为什么我希望看到Rust进入内核，这些类型的问题就会消失，让开发者和维护者有更多时间专注于真正的bug（即逻辑问题、竞态条件等）。

我完全支持将我们的C代码库转向使这些问题不可能发生，Kees、Gustavo和其他人正在做的工作是美妙且完全必要的。我们有3000万行的C代码，在不久的将来不会消失。这是一个值得称赞的努力，它不会停止，而且无论如何都不应该停止。

但对于新代码/驱动程序，在Rust中编写它们，因为这些类型的错误根本不可能发生（或者发生得少得多），这对我们所有人来说都是一种胜利，我们为什么不这样做呢？C++在不久的将来不会给我们带来任何这些好处，而C++语言委员会的问题似乎在指出，如果他们希望拥有任何可以长时间维护的代码库，那么他们最好尽快放弃那种语言。 Rust 还赋予我们以几乎不可能出错的方式定义内核 API 的能力。我们有许多过于复杂/棘手的 API，它们需要大量的维护者审查，仅仅是为了“确保你做对了”，这是我们的 API 随着时间的推移而演变的结果（你能以安全的方式使用 'struct cdev' 的多少种不同方式？）以及 C 语言不允许我们以使 API 更容易/更安全使用的方式表达 API。

迫使这些 API 的维护者重新思考它们是一件好事，因为这让我们为每个人清理它们，包括已经使用 C 的用户，从而使 Linux 更加完善。

诚然，Rust 绑定在某些地方看起来像是魔法，对我来说，一个几乎没有任何 Rust 经验的人，但我愿意学习和与那些站出来帮助这里的人一起工作。不愿意根据新的证据学习并改变（参见我关于阅读我们所有的内核 bug 的观点。） Rust 并非解决所有问题的“银弹”，但它确实能在众多地方提供帮助，所以对于未来的新事物，我们为什么不想要这样的东西呢？

Linux 是一个大家用来解决问题的工具，而在这里，我们有开发者表示“嘿，我们的问题是，我们想要为我们的硬件编写代码，而这些代码却不能自动消除所有这些类型的错误”。

我们为什么忽视这一点呢？

是的，我理解我们过度劳累的维护者问题（我自己也是其中之一），但在这里，我们有真正在做这项工作的人！

是的，混合语言代码库确实很粗糙，难以维护，但我们是内核开发者，该死，我们已经维护并加强了Linux，时间比任何人曾经认为可能的时间都要长。我们已经将我们的开发模式转变为一个运转流畅的工程奇迹，创造出别人从未能够实现的东西。添加另一种语言真的不应该成为问题，我们过去已经处理过更糟糕的事情，现在我们不应该放弃确保我们的项目在未来20年以上取得成功的愿望。面对新的好主意时，我们必须继续前进，并欢迎那些愿意加入我们实际工作的人，以确保我们共同成功。

感谢。

greg k-h