“

本文是 4.3 号 Rust 中文社群线上沙龙研讨会 【Rust 中文社群线上沙龙 20250403 ｜研讨 Rust 语言规范和 Rust for Linux 进入内核争议中的 C 维护者的技术论点-哔哩哔哩】 https://b23.tv/fTX8TpT 的文本参考。

什么是语言规范

语言规范是一种详细描述编程语言各个方面的文档，它为编程语言提供了一个明确的、权威的参考标准。语言规范定义了语言的语法、语义和行为，为验证、合规和标准化工作提供基础。对于任何成熟的编程语言来说，拥有一个正式的语言规范是至关重要的，它不仅使开发者能够清楚地了解语言的工作方式，还为编译器开发者提供了实现标准，确保不同编译器实现产生一致的结果。

语言规范通常包括语言的语法定义、语义规则、类型系统、内存模型、库功能以及其他特性的详细说明。它是开发者、研究人员和工具创建者的权威参考，也是确保语言实现一致性的基础。对于需要在高可靠性和安全关键系统中使用的编程语言，拥有正式的语言规范尤为重要。

为什么Rust语言之前没有语言规范？

尽管 Rust 于 2015 年发布了 1.0 稳定版，但直到最近，它一直没有官方的语言规范。随着 Rust 即将迎来其 10 周年，它已成为开发者中增长最快和最受喜爱的语言之一，这要归功于其速度、安全性和活跃的社区。然而，作为一种不断发展的开源语言，Rust 缺少了一份重要的文档——官方语言规范。

这种情况的存在有几个原因。首先，Rust 是一门相对年轻的语言，它的发展速度很快，语言特性不断演进。RFC（请求注释）机制被明确地用作构建共识的机制，而非规范。有时候，RFC 被接受后但在实现前，情况会发生变化。有时候，已接受的RFC可能永远不会被稳定化。这种快速发展的特性使得创建和维护一个正式的语言规范成为一项挑战。

其次，Rust 社区长期以来依赖于多种非规范性的文档来描述语言，包括 Rust 参考手册、标准库文档、Rust Nomicon 以及已接受的 RFC 集合等。这些现有资源都不完整，且不是可靠的依赖来源。没有一个统一、权威的文档来全面描述Rust语言的所有方面。

另外，创建一个全面的语言规范需要大量的资源和专业知识。2022 年 12 月，一个 RFC 被提交，鼓励 Rust 项目开始制定规范。经过深入讨论，该 RFC 于 2023 年 7 月获得批准，工作随即开始。直到最近，Rust 项目才有足够的资源来投入到这项工作中。

FLS 是什么？Rust 官方为何采用 FLS 作为语言规范蓝本？

FLS 全称为" Ferrocene 语言规范"（Ferrocene Language Specification），最初是由 Ferrous Systems 公司开发的Rust语言描述文档。FLS 是 Ferrocene 项目的一部分，这是 Ferrous Systems 和AdaCore 之间的合作，旨在将合格的 Rust 工具链引入安全关键环境。为了使这样的工具链获得资格认证，需要描述编译器在编译源代码时应如何表现，这意味着需要一个编程语言的规范。

FLS 的创建满足了对 Rust 在高保证领域的描述需求。FLS 是由现有的 Rust 文档编译而成，但以严格的结构呈现，以满足认证的要求。尽管 FLS 最初并不打算作为 Rust 语言的规范性定义，也不打算取代 Rust 项目的决策过程，但它的存在为 Rust 在安全关键行业的采用铺平了道路。

Rust 官方决定采用 FLS 作为语言规范的蓝本有几个关键原因：

由于 Rust 当时没有官方语言规范，也没有计划编写一个，FLS 代表了朝着以符合行业要求的方式描述 Rust 迈出的重要一步，特别是在高保证领域。
创建一个满足正式资格认证标准的替代规范是一项重大工作，可能不会成功。此外，Ferrocene 语言规范已经开始被安全关键消费者采用，他们正在使用它作为正式资格认证的基础，如果我们发布一个与 FLS 没有共同祖先的新 Rust 语言规范，他们将不得不重做这项工作。
FLS 是第一个满足安全关键系统使用要求的规范，已经被证明是成功的，为什么不利用这个现有的资源呢？

通过接受 Ferrous Systems 慷慨捐赠的 FLS，Rust 项目可以加速官方规范的开发过程。2025年3月26日，Rust 项目宣布将采用 FLS 作为正在进行的规范工作的一部分。FLS 的缩写原意是" Ferrocene 语言规范"，而在 Rust 项目中，将简单地称其为 FLS。

Rust 语言规范和 C/C++ 语言标准有什么本质不同？

Rust 语言规范与 C/C++ 语言标准在多个方面存在本质上的差异，这些差异不仅反映了技术实现的不同，更体现了两种语言设计哲学和社区治理模式的根本区别：

规范与实现的关系：Rust采用"实现驱动规范"的方式，而 C/C++ 则是"规范驱动实现"。Rust规范的目标不是改变语言如何发展；相关团队（语言团队、库API团队等）仍然负责Rust各自部分的发展，并将继续使用他们认为合适的流程（例如 RFC）。实际上，Rust的规范是对rustc编译器行为的描述，而非对编译器的约束。相比之下，C/C++ 标准是一套规则，所有声称符合C/C++ 的编译器都必须遵循这些规则。
标准化组织结构：C/C++ 标准由 ISO 国际标准化组织通过其委员会（如 ISO/IEC JTC1/SC22/WG21 ）制定，这是一个外部于任何具体实现的机构。而 Rust 规范则由 Rust 项目内部的团队负责维护和发展，使其与语言的实际实现保持紧密联系。
多实现与单一实现：C/C++ 标准旨在支持多个独立的编译器实现，如 GCC、Clang、MSVC等，这些实现必须符合标准才能被认为是有效的 C/C++ 编译器。Rust 规范并不以帮助开发替代Rust实现为主要目标，尽管替代编译器的作者可能仍会发现规范有用。Rust 本质上有一个权威实现（rustc），规范主要描述这个实现的行为。
更新周期与稳定性：Rust的发布将独立于规范批准过程进行。如果某个发布版本的规范尚未获得批准，那么该版本将在没有相关规范的情况下发布。Rust每六周发布一个新版本，语言特性可以快速演进。C++ 标准则通常每三年发布一次，更加强调向后兼容性和稳定性。
内存安全方面的根本差异：Rust 和 C++ 的主要区别在于它们对内存安全的处理方式。Rust在编译时强制执行严格的安全保证，防止空指针解引用和数据竞争等常见错误。相比之下，C++提供了更多的灵活性，但需要手动内存管理，如果处理不当，可能导致潜在的安全问题。这种差异直接反映在两种语言的规范/标准中：Rust规范保证了安全，而C/C++标准则定义了未定义行为的边界条件。
规范的目标用户：Rust 规范的目标是服务于 Rust 用户的需求，如不安全Rust代码的作者、那些从事安全关键Rust软件的人、语言设计师、Rust工具的维护者等。C/C++标准则更多关注编译器作者和需要确保代码可移植性的开发者。
决策过程：Rust 语言的变更首先通过RFC流程和实现，然后反映在规范中；而 C/C++ 标准的变更则首先在标准委员会中讨论和批准，然后由各个编译器实现。这种根本性的差异意味着Rust可以更快速地实验和采纳新特性，而规范则跟随实现。
版本控制和兼容性策略：Rust 通过其"版本"（Edition）机制管理语言的演进，允许引入潜在破坏性的变更，同时保持跨版本的互操作性。C/C++ 则通过标准的不同版本（如C++11、C++14、C++17等）来管理变更，这要求编译器厂商实现对多个标准版本的支持。
规范的透明度与社区参与：Rust 规范的开发过程完全开放，任何社区成员都可以查看并参与讨论。而 C/C++ 标准的开发虽然也接受外部意见，但核心决策通常在标准委员会的闭门会议中进行。
规范的形式化程度：C/C++ 标准常常使用精确的形式化语言来定义语言行为，而 Rust 规范则倾向于使用更接近自然语言的描述，结合代码示例和解释，使其更容易理解但可能在某些方面不那么精确。
定位与愿景：Rust 的特性集强调线程安全、内存布局控制和并发。其内置的安全性对现代软件和系统是一个优势。C/C++ 则更强调为系统程序员提供最大的控制力和性能，即使这可能以安全性为代价。这种不同的优先级直接反映在两者的规范/标准中。

Rust语言规范预计发布时间？

根据最新信息，Rust 语言规范的发布正在稳步推进。目标是将 Ferrocene 语言规范（FLS）合并到rust-lang 基础设施中，并以某种形式在某个（待定）名称下发布至少一个版本。预期它将以类似于其他 rust-lang 维护的书籍（参考手册、Rust书籍等）的方式集成到发布流程中。

Ferrous Systems 将把 Ferrocene 语言规范（FLS）转移给 Rust 项目，由规范团队（t-spec）所有。在 2025 年上半年，规范团队将把 FLS 以适当的名称整合到其设计和开发流程中，以及整个项目中。

这个目标旨在以一种既满足内部消费者又满足外部消费者的方式推进 Rust 规范，并在 RFC 3355 中设定的总体目标上取得进展。它还旨在为 2025 年下半年生产出第一个有用的规范版本做好准备，以及完成规范本身旁边可能需要做的任何辅助工作。

Rust 基金会和 Ferrous Systems 已经于 2025 年 3 月 26 日宣布了 FLS 捐赠的消息，标志着 Rust 语言规范工作的重要里程碑。未来，FLS 和 Rust 参考手册将共同被用于形成官方 Rust 规范。这是一个令人兴奋的结果。

综上所述，Rust语言规范预计将在 2025 年内正式发布其第一个版本（可能会在今年五月荷兰举办的 RustWeek 上宣布），这将为 Rust 生态系统带来重要的里程碑，并进一步推动 Rust 在高保证和安全关键应用领域的采用。

通过这次重要进展，Rust 迈出了成为更加成熟和规范化编程语言的关键一步。拥有正式语言规范将使 Rust 在企业和高安全要求环境中的应用更加广泛，也为其长期稳定发展奠定了坚实基础。随着Rust 继续在系统编程领域获得更多关注和采用，这份语言规范将为其提供更强大的支持和保障。

对 DMA 映射的 Rust 抽象的抵制：C 内核开发者的技术论点分析

事件背景

2025年1月，Abdiel Janulgue 提交了一系列补丁，旨在为 Rust 驱动程序提供对内核 DMA 映射子系统的访问能力。这些补丁添加了一个小型 Rust 模块，提供足够的支持来为驱动程序设置连贯映射（cache-coherent memory 中的长期映射）。虽然这项工作只覆盖了 DMA API 的一部分，但对于更简单的设备来说已经足够了。

然而，DMA 映射层的主要维护者 Christoph Hellwig 拒绝了这一提交，他简短地表示："请不要在 kernel/dma 中放入 Rust 代码"（尽管补丁实际上并没有在该目录中放置任何代码）。这一拒绝引发了一场关于 Rust 在 Linux 内核中地位的争论，最终导致 Linus Torvalds 介入并明确表态支持 Rust 代码的合并，而 Hellwig 则辞去了 DMA 映射子系统的维护者职位。

C 内核开发者的技术论点分析

1. 跨语言代码库的维护性问题

Hellwig 的核心技术论点是关于维护性的考虑。他认为引入多种编程语言会使 Linux 内核作为一个整体"不可能维护"。在他看来，Linux 之所以能够长期存活，是因为它没有内部边界，而添加另一种语言完全打破了这一点。

从技术角度看，这一论点有一定合理性：

代码库复杂性：多语言代码库确实增加了系统的复杂性，尤其是在像 Linux 内核这样的大型、关键系统中。
开发工具链差异：不同语言需要不同的编译器、调试工具和开发环境，可能增加维护者的工作负担。
接口稳定性：C 和 Rust 之间的接口需要格外谨慎设计，以确保长期稳定性。

2. C 接口设计与 Rust 绑定的兼容性

Hellwig 坚持认为"DMA API 的接口应该保持在可读的 C 代码中，而不是在奇怪的绑定中，这样它才能保持可搜索和可维护"。他担忧 Rust 绑定可能使 C 接口设计变得复杂化。

这一论点的技术合理性在于：

接口设计约束：为了兼容 Rust 的类型系统和所有权模型，C 接口可能需要特殊设计或添加额外约束。
API 演进受限：Hellwig 担心 C 子系统开发者在修改代码时必须考虑对 Rust 绑定代码的影响。这意味着对 C 中的结构或内部函数的任何调整可能需要对 Rust 代码进行并行更改。

3. 代码查找和调试的困难

Hellwig 提到了"可搜索性"(greppable)问题。在单一语言代码库中，开发者可以使用简单的文本搜索工具（如 grep）来查找函数和变量的所有引用。

这一考虑的技术合理性：

跨语言追踪：在多语言环境中，函数调用链可能跨越语言边界，使得跟踪调用流程变得更加复杂。
调试挑战：不同语言的调试工具和技术不同，可能使解决跨语言问题变得更加困难。

4. 对 DMA 子系统本身的担忧

Hellwig 特别担心 Rust 渗透到内核的核心子系统中。DMA（直接内存访问）是一个关键的内核子系统，负责在外围设备和内存之间直接传输数据，绕过 CPU。

这一担忧的技术基础：

核心子系统的稳定性：DMA 子系统是内核的关键部分，其稳定性对整个系统至关重要。
性能敏感性：DMA 操作通常是性能关键型的，任何额外的抽象层都可能引入开销。
硬件直接交互：DMA 涉及直接与硬件交互，对内存布局和同步有严格要求。

5. Rust 抽象的实现方式争议

争论的另一个技术层面是关于如何实现 Rust 抽象。Hellwig 建议每个 Rust 驱动程序应该有自己的 C 绑定，而不是创建一个集中的抽象层。然而，Rust 开发者认为集中维护一套 Rust 抽象更有利于代码质量和一致性。

这一争议的技术考量：

抽象的一致性：集中的抽象确保所有 Rust 驱动程序以一致的方式与 DMA API 交互。
维护开销：分散的抽象可能导致重复代码和不一致的实现。
API 变更响应：当 DMA API 发生变化时，如果使用集中抽象，只需修复一套被所有人使用的抽象；而分散抽象则需要一个接一个地修复众多驱动程序。

Linus Torvalds 的技术反驳

Linus Torvalds 最终介入并支持 Rust 代码的合并。他的技术论点包括：

代码隔离：Torvalds 指出，问题中的补丁根本没有触及 DMA 层。它只是 DMA API 的另一个用户，位于完全独立的子目录中，没有以任何方式更改 Hellwig 维护的代码。
API 使用权限：他强调 Hellwig 的做法本质上是在说"作为 DMA 维护者，我控制着 DMA 代码的使用方式"，而这不是内核开发的工作方式。API 的目的就是供其他代码使用，维护者不能控制谁或什么可以使用他们的代码。
维护责任界限：Torvalds 明确表示，Hellwig 不被强制接受任何 Rust 代码或关心 DMA 代码中的任何 Rust 代码。他可以忽略它。但"忽略 Rust 一方"自动意味着他对 Rust 一方没有任何发言权。这一点明确了维护责任的边界。

其他专家的技术意见

其他内核开发者也提供了一些技术观点：

内存安全优势：支持 Rust 的开发者强调了其内存安全特性对于驱动程序开发的价值。Google 的内核安全工程师和长期内核贡献者 Kees Cook 表示："我认为专注于替换现有代码没有任何理由——这样做实际上会带来很大的风险。但用 Rust 编写新的东西是非常有效的"。
增量方法：许多支持者建议采用增量方法，首先为新驱动程序添加 Rust 支持，而不是尝试重写现有代码。这减少了风险并允许生态系统逐渐适应。
不安全代码隔离：一些开发者指出 Rust 的价值在于创建"零成本抽象层"，将不安全的硬件交互封装起来，然后在更高级别使用安全的 API。这种方法可以提高整体代码质量和安全性。

争议的结果与影响

这场争议最终以几个重要的发展结束：

Torvalds 的决定：Linus Torvalds 明确表示 Rust DMA 抽象代码将被合并，确立了 Rust 在内核中的地位。
维护者变更：Christoph Hellwig 辞去了 DMA 映射代码的维护工作，由 Marek Szyprowski 接任。这表明了内核领导层对 Rust 集成的坚定支持。
社区反思：这一争议引发了关于维护者责任、社交媒体在内核开发中的作用以及技术关切与社区动态之间平衡的更广泛讨论。

技术论点的正确性评估

评估 C 内核开发者反对 Rust 抽象的技术论点的正确性：

跨语言维护性问题：这一担忧有一定合理性，但内核已经包含多种语言（C、汇编语言），而且现代开发工具可以缓解许多跨语言开发的挑战。
接口设计约束：这是一个有效的技术考量，但可以通过良好的设计和明确的接口契约来管理。Rust 团队提出的解决方案——由他们负责维护抽象层——是一个合理的妥协。
代码查找和调试：这一担忧在技术上有一定道理，但现代 IDE 和开发工具能够处理跨语言引用和调试。这更多是工具和习惯的问题，而非根本性技术障碍。
核心子系统担忧：对关键子系统稳定性的关注是合理的，但 Rust 代码实际上并不修改现有 C 代码，只是提供一个抽象层。风险相对可控。
抽象实现方式：从技术角度看，集中维护的抽象在维护效率和一致性方面优于分散的实现，Hellwig 的建议实际上可能会增加长期维护负担。

结论

从技术角度看，C 内核开发者对 Rust 抽象的担忧部分是合理的，尤其是关于跨语言代码库维护性和接口设计约束的考虑。然而，这些问题大多可以通过良好的设计和明确的责任划分来解决。

Linus Torvalds 的决定反映了一个平衡的技术判断：允许 Rust 代码作为 C API 的用户存在，同时保持 C 代码维护者的自主权。这种方法既承认了跨语言开发的挑战，又认可了 Rust 在提高内核安全性和吸引新开发者方面的潜在价值。

最终，这场争议不仅涉及技术问题，也反映了开源社区如何适应和整合新技术的挑战。它为 Linux 内核如何演进以纳入现代编程语言的优势，同时保持其核心价值和稳定性，提供了重要的案例研究。

小结

随着 Rust 语言规范开始制定到最终的发布，Rust 语言版图算是补上了缺失的一环。曾经 Linux 内核中因为 Rust 语言缺乏规范而抵制 Rust 语言的声音也将被终止。随着 Linus 的发声，Rust 进入 Linux 内核已经是板上钉钉的事情了。

这也意味着，Linus 也和 Rust 基金会成员里的各大 IT 巨头 Google / 微软 / 华为 / Meta 等拥有一致的认同，Rust 是下一代系统级语言。

感谢阅读，最后也推荐大家看 B 站视频讨论。