关于Linux内核的开发到底是应当坚持使用单一的C语言linux内核编译，还是可以适当引入Rust，仍然是整个Linux社区悬而未决的事情。
近来，尝试将Linux移植到苹果自研M系列芯片平台的AsahiLinux负责人HectorMartin，由于与反对引入Rust的Linux维护者发生了冲突，故而宣布辞去AppleSilicon的维护者职务，并退出AsahiLinux项目。此后，Nouveau驱动程序开发人员KarolHerbst也因对Linux内核现在“有毒”的环境倍感沮丧，辞去了Nouveau维护者职务…
在这一系列动乱过后，好多人觉得，Linux项目高层再不出面，似乎Linux社区就要“四分五裂”了。
这不，前有Linux内核维护者透漏，LinusTorvalds私下表示，他将不顾部份维护者的反对，继续推动Rust代码的合并。后就有在明日，Linux的一把手GregKroah-Hartman出面亲自为Rust语言站台。在一封Linux内核电邮列表贴子中，GregKroah-Hartman鼓励你们使用Rust来编撰新的内核代码或驱动程序，而不是继续使用C语言。
Linux维护者的反对声仍然在持续
带来“Linus将推翻维护者对内核中Rust代码的否决权”这一消息的并非是Linus本人，而是DMA映射助手及内核其他多个其他领域的维护者ChristophHellwig。
Hellwig常年以来始终对在Linux内核中引入Rust及其他次要编程语言持批判心态，尤其对Rust在内核中的应用表示忧虑。
在Hellwig看来，如今好多Rust代码像是一个企图消弭巨大语义差别的怪物，这种“怪物”已经渗透到每一个小子系统和库中。
「这些绑定像“癌症”一样漫延到各个地方，并迅速从一个容许并追求全局改进的软件项目，转向日渐降低的隔离化。这将使Linux弄成一个用多种语言编撰的项目，而没有明晰的手册说明在何处使用何种语言。虽然在绑定之外，因为内核数据结构（如无处不在的数组）的侵入性和自引用特点，许多代码也不会是十分地道的Rust。我们是否既对不住这些企图将现有代码库带入更安全空间的人，也对不住这些用Rust进行系统编程的人？」Hellwig说。
此后，Hellwig继续补充道：
“像这样工作的代码库是我最担心的，由于缘由Xlinux通配符，总须要不断地从语言A重讲到语言B，之后又由于缘由Z重新写回来。这还没有考虑到Linux中常见的‘创造性’的内斗。
我想理解这个Rust‘实验’的目标是哪些：假如我们想修补现有的显存安全问题，我们须要为现有代码做改进，并找到方式将其改建。近来有好多工作早已投入其中，但是我们须要做更多。但这也显示出核心维护者对于检测整数溢出或编译器强制同步（比如clanghreadsanitizer）等琐事的排斥。我们该怎么消弭内核的一部份不接受相对简单的安全改进规则与另一部份强制执行严格规则之间的差别呢？
假如我们只是想让驱动程序编撰更容易，这么采用一种新语言来做这个，会降低更多的工作量，并加重早已超负荷工作的核心基础设施维护者的负担。”
话虽这么，ChristophHellwig直言，责怪再多虽然都没有用。他补充道，LinusTorvalds在私下里曾表示，虽然一些维护者反对，他依然会推动Rust代码的合并。
也就是说，作为一个Linux开发者或维护者，不管是否乐意，都必须处理Rust代码的相关问题。
Linus将坚持推动RustforLinux项目，强制合并Rust内核代码
与此同时，ChristophHellwig还分享了一个经过Linux社区内部讨论而发布的一个名为《Rust内核策略》（）的页面，该页面致力解答怎样在子系统中引入Rust、谁来维护Rust代码，以及维护人员是否应当以相同标准对待Rust代码等问题。
依据该页面内容显示，关于内核中Rust代码的维护，根据传统的内核维护新政，由列举的维护者负责。具体来说，Rust子系统负责一些核心功能以及没有其他维护者的API，但它并不承当内核中所有Rust代码的维护任务，由于这样做在规模上无法管理。其实这么，团队还是乐意在须要时提供帮助，目标是通过构建一个混和团队，帮助整个内核引入Rust。最终，Rust子系统可能也会作为Rust代码的“后备维护者”，类似于akpm作为C代码的最后“救火球员”。
其次，关于C语言更改是否可能造成Rust编译失败的问题，依然会遵守常规内核新政。默认情况下，假如已知修改会造成建立失败（包括Rust代码），则不应递交这种修改。但是，对于Rust代码，一些子系统可能准许暂时破坏Rust代码。这样做是为了让个别子系统才能友好地采用Rust，同时不降低现有维护者修补C语言问题的负担。似乎可以暂时破坏Rust代码，但问题应尽早修补，理想情况下在Linus晓得之前就解决。
此外就有现有Linux维护者是否应当像对待C代码一样对待Rust代码这类的心态问题，该页面写道，理想情况下，维护者确实应当根据相同的标准进行处理，但在Rust初步引入时，可能毋须强求这一点。
此举的目的是希望Linux维护者不要由于感觉难以像处理C代码一样及时修补Rust代码的问题而拒绝使用Rust。虽然她们有兴趣尝试，也不应倍感过大的压力。为此，依据不同子系统的情况，Rust可能被视为一个新技术，而新技术总有可能出现问题。
但是linux内核编译，Hellwig在自己发的一封贴子中明晰表示，“我觉得这份新政文件并不是很有用。现今的规则是Linus可以逼迫你做任何他想做的事（虽然这是他的项目），我觉得他须要明晰强调这一点，包括对贡献者的期望。对于我来说linux漏洞扫描，我可以处理Rust本身，我也很希望将内核带入一个更安全的显存世界，但处理一个不受控的多语言代码库无疑会让我把课余时间投入到其他事情上。我听过一些其他人也有类似的看法，但并不是每位人都像我一样坦承不讳。”
Linux一把手：3000万行C代码不会很快消失，但应当尝试用Rust编撰新的代码和驱动程序
截止目前，Linus并未就此事公开出面回应。不过在以《Rust内核策略》这一电邮列表贴子讨论中，在Hellwig发布自己的想法不久后，素来有着“Linux的一把手”之称的GregKroah-Hartman公开了自己的心态——支持Rust步入Linux内核。
GregKroah-Hartman是Linux内核的核心维护者之一，负责多个子系统的维护，包括驱动程序和内核稳定性方面的工作。据悉，他也是Linux常年支持版本（LTS）的维护者之一，具有很高的影响力和权威性
GregKH提出，绝大多数内核漏洞都由于C语言中的“愚蠢的小极端情况”造成的，这种问题在Rust中完全不存在。他支持逐渐从C代码库转向Rust代码，由于在Rust中，这种显存安全漏洞和C语言的其他不足不会发生。
Greg承认，所有的Linux内核C代码不可能很快消失，但他确实希望新代码和驱动程序才能使用Rust，以防止C语言代码中的漏洞和问题。
以下是Greg在LKML上发布的完整内容：
「作为一个过去15年多来几乎见证了每一个内核bug修补和安全问题的人（希望所有问题都能最终步入稳定树，尽管有时当维护者/开发者忘掉标记为bug修补时，我们会漏掉一些），但是见到每一个发布的内核CVE，我想我可以就这个话题发表一些想法。
我们遇见的大多数bug（按数目而非质量/严重性来算）都是因为C语言中的荒谬的小极端情况导致的，而这种在Rust中完全消失了，比如简单的显存覆盖（尽管Rust不能完全捕获所有这种问题）、错误路径的清除、忘记检测错误值，以及use-after-free等错误。正因这么，我希望见到Rust才能步入内核，这种类型的问题都会消失，让开发者和维护者有更多时间去关注这些真正的bug（即逻辑问题、竞争条件等）。
我完全支持将我们的C代码库逐渐转向那些问题未能出现的方向，Kees、Gustavo等人所做的工作十分棒，完全是我们须要的。我们有3000万行C代码，这种代码在未来几年内不会消失。这是一项值得的努力，不会停止，也不应当停止。
并且对于新代码/驱动程序，使用Rust来编撰它们，由于这种类型的bug根本不会发生（或则发生得少得多），对我们所有人来说都是一种胜利，为何我们不那么做呢？C++在未来几六年内不会给我们带来这种东西，但是C++语言委员会的问题其实也强调，倘若你们想拥有一个能常年维护的代码库，就最好尽早舍弃C++。
Rust还让我们能否以一种几乎不可能出错的方法来定义内核中的API。我们有太多难度大、棘手的API，维护者须要进行大量的审查，以“确保你做对了”。这是由于我们的API多年来不断演进（例如有多少种方式可以安全地使用‘structcdev’？），而C语言难以让我们以更安全/简便的形式抒发API。促使我们这种API的维护者重新思索这种API是件好事，由于这促使我们能否为每位人清除它们，包括C语言用户，这将整体上让Linux显得更好。
是的，Rust绑定对我来说如同魔法一样，作为一个几乎没有Rust经验的人，但我乐意学习，并与这些早已站下来帮助我们的开发者一起工作。我们不能由于新证据的出现而不愿学习和改变。
Rust并不是能解决所有问题的“银弹”，但它肯定能在许多地方提供巨大帮助。这么，为何我们不想要它呢？
Linux是一个每位人都拿来解决她们问题的工具，我们这儿有一些开发者在说：“嘿，我们的问题是，我们想为我们的硬件编撰代码，而这种代码不能手动地出现所有那些类型的bug。”
我们为何要忽略这一点呢？
是的，我理解我们过度疲累的维护者问题（我自己也是这种人之一），但如今我们有开发者在实际做这项工作！
是的，混和语言的代码库很复杂，维护也很困难，但我们是内核开发者，靠我们，我们早已比任何人想像的更好地维护和加强了Linux。我们把开发模型转弄成了一个精密的工程奇迹，创造了其他任何人都难以做到的事情。加入另一种语言真的不应当是问题，我们过去处理过更糟糕的事情，我们不应当舍弃现今确保我们的项目就能在未来20多年继续成功的机会。我们必须在面对新的好主意时继续前进，并拥抱这些乐意加入我们，真正做这项工作，确保我们都能一起成功的人。
感谢！
——gregk-h」
业界网友的想法
现在，Linux项目高层对Rust语言的心态早已渐渐明朗。其实，仍有一些声音觉得，接受Rust所带来的挑战并不值得。有些人觉得，许多Rust所倡导的优势，虽然可以通过其他方法实现。诸如，边界检测和一些类似RAII的显存管理优化，可以在没有Rust的情况下通过其他工具做到，因而降低显存安全问题。据悉，有人强调，Rust代码的可读性和美观性也让人不免形成埋怨，甚至不愿被迫处理这些代码。
但更现实的是，有网友表示：“C语言的最大问题在于后继乏人，这是Linux社区面临的最严峻挑战。现在，Linux中许多C语言的写法早已成了‘祖传技艺’，这种特殊的用法未能接手和维护。假如没有老一辈的弘扬，后续开发者很难接过这个重任。换种语言，其实能为项目注入新的活力，保持常年的维护。”
虽然这么，无论是否乐意，Linux社区虽然都须要为应用Rust语言而做好打算了。
参考：
@gregkh/
