社区热点

编辑：张汉东

【RFC】Rust : Linux 内核的第二语言

以下是 RFC 的一些摘要：

We believe that, even today, the advantages of using Rust outweighs the cost.

内核中支持 Rust 去编写驱动和一些类似 “叶子” 模块，而不打算用 Rust 重写内核核心和内核子系统。

在 Linux 内核中对使用 Rust 的期望：

用 Rust 新编写的代码能降低内存安全/ 数据竞争 / 逻辑 Bug 的风险
维护人员对重构和接受模块补丁更有信心
新的驱动程序和模块变得更容易编写
使用新的现代的语言，吸引更多的人参与内核开发
通过利用Rust工具，建立的文档指南。例如，要求记录所有公共API，安全前提条件，“Unsafe”块和类型不变式。

Rust与C相比也有缺点：

围绕内核开发的 C 语言工具有很多年的积累，但是，如果内核 Rust 使用量上来，也会有相应工具。
Rust 基于 LLVM 的单一实现。目前通过第三方的努力来改善这种情况，比如 GCC 前端，基于 Cranelift 的 rust 后端，以及减少 bootstrapping chain 的 mrustc。
未标准化。虽然尚不清楚标准化是否会对内核有利，但在任何情况下都有几点可以最小化此问题：Rust稳定性承诺，广泛的文档，WIP参考，详细的RFC等。
编译速度太慢。
目前需要一些 nightly 功能，目标是一年内帮助 rustc 稳定这些功能，或者是，找到替代的稳定的功能。在这里维护相关报告：https://github.com/Rust-for-Linux/linux/issues/2
其他。

「我们认为Rust很可能会就像C一样，成为系统编程的重要组成部分」

关键设计选择

Rust内核模块需要一些共享代码，即通过配置选项（CONFIG_RUST）启用。这使得单个模块更小。此支持包括：
- Rust 标准库。当前包含了 alloc 和 core，未来可能仅有 core 的子集。

包装内核API 的安全抽象 API，目的是为了让 Rust 编写的模块中尽可能减少 Unsafe 代码的数量。
其他。例如“模块！”过程宏，编译器内置函数，生成的绑定和帮助程序等。

用Rust编写的模块永远不要直接使用C内核API。在内核中使用Rust的全部要点是，我们开发了安全的抽象，因此模块更易于推理，因此更易于查看，重构等。此外，通过“ bindgen”（正式的Rust工具）即时生成与内核C端的绑定。使用它可以避免在Rust方面更新绑定。
在Rust代码库中，大多数文档都是在Markdown中与源代码一起编写的。我们遵循此约定，因此尽管在Documentation / rust /中有一些常规文档，但大多数实际文档都在源代码本身中。

强制执行自动代码格式，使用 clippy/ fmt 等。例如，这意味着4个空格用于缩进，而不是制表符。我们认为重要的是保持格式自动化。

为避免将GPL符号公开为非GPL（甚至间接），将内核中的所有Rust支持符号导出为GPL。

目前状态

目前提供的 Rust 支持是实验性的，因为还有很多细节需要完善，比如内核API需要安全抽象等。但是，现在可以编写一些模块等原型了。

目前支持 Clang 构建内核，支持 x86_64，arm64和ppc64le等衍生架构，以及 RISC-V等。

上游计划

与往常一样，尽早进入主线是解决所有遗漏细节的最佳方法，但是，我们何时提交它们取决于我们收到的有关此RFC的反馈以及高层维护者的总体看法。

我们希望得到反馈的另一个主题是 kernel crate： https://rust-for-linux.github.io/docs/kernel/

Linus 对 Rust 进内核给出了珍贵的指导意见


So I replied with my reactions to a couple of the individual patches, but on the whole I don't hate it.

HOWEVER.

I do think that the "run-time failure panic" is a fundamental issue.

I may not understand the ramifications of when it can happen, so maybe it's less of an issue than I think it is, but very fundamentally I think that if some Rust allocation can cause a panic, this is simply fundamentally not acceptable.

Allocation failures in a driver or non-core code  and that is by definition all of any new Rust code can never EVER validly cause panics. Same goes for "oh, some case I didn't test used 128-bit integers or floating point".

So if the Rust compiler causes hidden allocations that cannot be caught and returned as errors, then I seriously think that this whole approach needs to be entirely NAK'ed, and the Rust infrastructure - whether at the compiler level or in the kernel wrappers - needs more work.

So if the panic was just some placeholder for things that _can_ be caught, then I think that catching code absolutely needs to be written, and not left as a to-do.

And if the panic situation is some fundamental "this is what the Rust compiler does for internal allocation failures", then I think it needs more than just kernel wrapper work - it needs the Rust compiler to be *fixed*.

Because kernel code is different from random user-space system   tools. Running out of memory simply MUST NOT cause an abort.  It needs to just result in an error return.

I don't know enough about how the out-of-memory situations would be triggered and caught to actually know whether this is a fundamental problem or not, so my reaction comes from ignorance, but basically the rule has to be that there are absolutely zero run-time "panic()" calls. Unsafe code has to either be caught at compile time, or it has to be handled dynamically as just a regular error.

With the main point of Rust being safety, there is no way I will ever accept "panic dynamically" (whether due to out-of-memory or due to anything else - I also reacted to the "floating point use causes dynamic panics") as a feature in the Rust model.

           Linus

详细：https://lkml.org/lkml/2021/4/14/1099

Google: Linux 内核中使用 Rust

Google 发布的这篇博文中宣布支持 Rust ，并且还给出一个驱动开发示例来对比 Rust 和 C 。

https://security.googleblog.com/2021/04/rust-in-linux-kernel.html

字节码联盟成为非营利组织并且迎来新成员

字节码联盟（Bytecode Alliance）成为了 501(c)(6) 非营利组织，并且有新成员加入 Arm, DFINITY Foundation, Embark Studios, Google, Shopify, 和 University of California at San Diego 。

一直以来的工作：

推动 nanoprocess 并推动标准化，包括 WASI/ Interface Types/Module Linking等。
Cranelift WebAssembly编译器创建了一个新的代码生成后端，重点关注性能和安全性。这个新的后端是由Fastly，Mozilla，Intel和Arm之间紧密合作创建的，现在是Wasmtime和Lucet的默认后端，并且Fastly最近对该技术进行了全面的安全评估，并为 Compute @ Edge 切换到了这个新后端。
改进了协作流程；例如，引入了RFC流程来提高可见性，并能够集中讨论我们核心项目的重大变化

未来社区治理

我们欢迎新成员加入字节码联盟。在加入新成员的同时，在接下来的几个月中，我们将为技术指导委员会（TSC）和董事会全面定义章程，作为引导阶段的一部分。在此期间结束时，我们将组织理事会和TSC选举，以全面建立Bytecode Alliance的开放治理模型。更多细节将在不久的将来出现。

https://bytecodealliance.org/articles/bytecode-alliance-update