June 2025 program management update #1668
Conversation
|
I'd like this to merge after #1667 is published so I can link it from here. cc @ojeda: If you have time to check the Rust for Linux section, I'd be really grateful. I want to make sure it's not misrepresenting anything. cc @walterhpearce: same for the |
Co-authored-by: Miguel Ojeda <[email protected]>
|
@ojeda thank you for your suggestion! I've added more context to Rust for Linux so I'd appreciate one more look if you don't mind. Tried to explain why we're doing this too. I also want to do a similar things for the crates.io verification/mirroring |
|
|
||
| ## Rust for Linux | ||
|
|
||
| [Rust for Linux][rfl] is an ongoing effort (started in 2020) to add support for Rust to the Linux kernel. This will let you write kernel drivers in a memory safe language, with hopefully fewer bugs and nicer tooling. And empower people outside of the traditional low-level C background to write kernel code. |
There was a problem hiding this comment.
| [Rust for Linux][rfl] is an ongoing effort (started in 2020) to add support for Rust to the Linux kernel. This will let you write kernel drivers in a memory safe language, with hopefully fewer bugs and nicer tooling. And empower people outside of the traditional low-level C background to write kernel code. | |
| [Rust for Linux][rfl] is an ongoing effort (started in 2020) to add support for Rust to the Linux kernel. The project allows to write kernel code, such as drivers and other modules, in a memory safe language, with hopefully fewer bugs and nicer tooling. In addition, [one of its goals](https://lore.kernel.org/lkml/[email protected]/) it to allow more people get involved overall in developing the kernel thanks to the usage of a modern language. |
There was a problem hiding this comment.
I suggested the rewording above because it already allows people to do that (e.g. we already have drivers in-tree) and because it is not only for drivers. In addition, since you talked about rationale/goals, I linked to the original RFC and reused a sentence out of it.
|
|
||
| [rfl]: https://rust-for-linux.com/ | ||
|
|
||
| The project currently has to rely on unsafe Rust. This makes it less appealing for companies and individuals as unstable features can by definition change or even be removed. We want there to be minimal (ideally zero) churn on Rust code that's been accepted to the kernel. |
There was a problem hiding this comment.
| The project currently has to rely on unsafe Rust. This makes it less appealing for companies and individuals as unstable features can by definition change or even be removed. We want there to be minimal (ideally zero) churn on Rust code that's been accepted to the kernel. | |
| The project currently has to rely on unstable Rust. This makes it less appealing for companies and individuals as unstable features can by definition change or even be removed. We want there to be minimal (ideally zero) churn on Rust code that's been accepted to the kernel. |
|
|
||
| There's been an ongoing collaboration with the Rust Project to get the language, compiler and tooling to a point where it can be completely compiled on stable Rust. | ||
|
|
||
| [This was one of the Flagship goals in the first half of 2025][rflh1]. |
There was a problem hiding this comment.
Since you mention this, I would suggest also mentioning it was a flagship goal in 2024H2 too (i.e. since the beginning of the goals), since it reinforces the notion that it has been an important goal of upstream Rust: https://rust-lang.github.io/rust-project-goals/2024h2/rfl_stable.html
|
|
||
| [rflh1]: https://rust-lang.github.io/rust-project-goals/2025h1/rfl.html | ||
|
|
||
| This effort requires close collaboration with the Lang and Compiler teams and someone who can bridge the gap between the two projects. Until now, that was done by Niko Matsakis. |
There was a problem hiding this comment.
| This effort requires close collaboration with the Lang and Compiler teams and someone who can bridge the gap between the two projects. Until now, that was done by Niko Matsakis. | |
| This effort requires close collaboration with the Lang and Compiler teams, among others, and contact points on both sides to bridge the gap between the two projects. Until now, that was done by Niko Matsakis et al. on the Rust side and Miguel Ojeda et al. on the Rust for Linux side. |
Rendered