The Rust for Linux politics mess should be laid squarely at Linus' feet. He's the BDFL. He approved adding Rust to Linux, and he massively failed at communicating what that even meant. If he wants Rust in the kernel, he needs to kick some maintainers in the ass and get everyone aligned.
The page uses "our" and "we" a bunch of times, but doesn't say who this "we" is. The implication from the "Contact" page seems to be that this is some "Rust for Linux" group that may or may not be well defined.
Which is fine, but then the document also doesn't cite most of the things it states, and isn't always clear on what's established fact/standard and what's this group's opinion. For eg.
> Should maintainers treat Rust code up to the same standards?
> Ideally, and eventually, yes. However, when they are starting out, not necessarily.
Sections like this have no indicator for whether this is opinion they are stating, an argument they're presenting, or an already-decided kernel policy that they're citing.
---
> On the costs side, [...] most Rust language features we used were stabilized
The fact that this has to be specified - and still qualified with "most" - is a big part of the problem with this.
I'm an outsider, only submitted one tiny patch years ago, but it seems like this Rust for Linux initiative will end badly if it's not stopped. You have so many people involved in work on this open source OS written in C and they will be pushed to accepting foreign code. Rust, as a very complex and opinionated language, is not an easy choice to accept for C developers. If the push continues, maybe we will see the existing maintainers leaving?
Seems like a good tool for ensuring everyone is aligned.
Nit: The policy document seems inconsistent in its authoritative tone. In some sections, it hand-waves and punts to an external resource. For example: "Yes, there are key kernel maintainers who support Rust in the kernel. [Check out this PDF of keynote slides and figure it out yourself]."
I feel like Rust just isn’t stable or mature enough as a language for moving Linux towards it to make sense.
Currently feels like you need a PhD in programming languages to use it effectively. Feels like Haskell in many ways.
This answer seems like a big spin:
> Is Rust for Linux driven by the "Rust community"?
> No, the people involved around Rust for Linux come from different backgrounds and organizations. Some are kernel maintainers, some are Rust experts. Some are hobbyists, some are employees at large corporations
> Particularly, it is not an effort driven by the Rust Project nor the Rust Foundation. In fact, Rust for Linux was founded by a Linux kernel maintainer as a hobby, it is not an effort driven by the Rust Project nor the Rust Foundation. In fact, Rust for Linux was founded by a Linux kernel maintainer as a hobby
The Rust Project says R4L is a “flagship” goal: https://rust-lang.github.io/rust-project-goals/2024h2/goals.... I recall Josh Triplett saying R4L was a big priority for Rust this year; he pledged his support.
Also, didn’t the author of this updated doc (Miguel Ojeda[1]) resign from R4L? I’m not sure what his role is here.
Edit: [1] see https://lore.kernel.org/rust-for-linux/CANiq72m-R0tOakf=j7BZ...
It’s all open source and therefore mostly unpaid volunteer driven, but it doesn’t really feel like there is truly a policy. Every week we see a story here about a kernel maintainer complaining about Rust and Linus refusing to actually apply any sort of rules to the maintainers.
It just seems very aimless and unfocused.
The CC list is interesting: https://lore.kernel.org/rust-for-linux/CANiq72m-R0tOakf=j7BZ...
Summary: Why Rust Cannot Be Fully Integrated into the Linux Kernel
Rust-for-Linux (R4L) is an experiment, but it faces fundamental obstacles due to the Linux kernel’s monolithic structure, constantly changing APIs, reliance on GCC, and existing development model.
Key Challenges: 1. Unstable Kernel APIs – Linux kernel APIs frequently change, making Rust integration difficult without a stable ABI, which contradicts Linux’s development model. 2. GCC vs. LLVM Conflict – The Linux kernel primarily relies on GCC, while Rust requires LLVM. This creates fragmentation in the toolchain. 3. Dual-Language Complexity – Developers must master both C and Rust, leading to recruitment and maintenance challenges. 4. Memory Model Incompatibility – Rust’s ownership model does not align well with many kernel subsystems, requiring workarounds that reduce its safety benefits. 5. Monolithic Kernel Issues – Linux is designed as a monolith, where all components deeply interact. Introducing Rust without a complete rewrite results in complex dependencies and maintenance overhead.
Only Viable Solution: A Full Fork
A Rust-based kernel requires a complete fork from Linux, rewriting everything in Rust. However, such a project would no longer be Linux but an entirely new OS.
Thus, Rust cannot become a true part of the Linux kernel without fundamentally breaking its principles. The real question is: Should a new Rust-based OS replace Linux, or should Rust-for-Linux be abandoned?
Any doctrine similar somehow never made it, unless the prog lang is scheme or guile or racket but i consider Tcl a lisp in disguise.
My prediction:
Linus will retire and leave the Rust mess for other to live with.
[flagged]
[flagged]
Please fix rust to make its toolchains statically link libgcc. Bug since 2015...
Probably more relevant are the Rust version policies: https://rust-for-linux.com/rust-version-policy And the policies around unstable Rust features (at least they are acknowledged as a problem): https://rust-for-linux.com/unstable-features
They don't say what their policy is regarding building the C parts with GCC and the Rust parts with the LLVM toolchain (including the Clang parts that bindgen uses). Some kernel developers are very much opposed to mixing GCC and Clang in a kernel build (to put it mildly), and some version combinations are known not to work. On the other hand, it seems somewhat unlikely that distributions would abandon building the kernel with GCC just to be able to use drivers written in Rust.