Rust kernel policy
rust-for-linux.com
rust-for-linux.com
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.
My understanding is this concern was broached very early in the Rust for Linux project and Greg Kroah Hartman explicitly signed off on "building the C parts with GCC and the Rust parts with the LLVM toolchain". See: https://news.ycombinator.com/item?id=24335831 and https://lwn.net/Articles/829858/
> And the policies around unstable Rust features (at least they are acknowledged as a problem):
I am amazed at what short memories many have. I remember when clang couldn't build the kernel. I remember when GCC required many special extensions to the C language to even compile the kernel. I think GCC may still require some of these and clang/LLVM may require emulation of the same.
Now, Rust gets the surprise news they may be included in the kernel and they have worked diligently to stabilize certain unstable features. Can you imagine what kind of rudder movement something similar would take to turn the C/C++ committees/tankers? Obviously, language "stability" isn't the issue you make it out to be, because, for decades, the Linux kernel required GCC extensions.
I'm not sure there is as much in that distinction as you hope for 2 reasons: 1) what is the actual stability guarantee of GCC extensions? 2) what is the cash value of your distinction to the point I was making?
Re: 1, do you not believe GCC has and would modify or remove an extension which conflicts with C standard behavior? I know of instances where GCC C++ definitely deprecated an extension after it was implemented according to the standard.
Re: 2, my actual point was it's fine, even good, that that that Rust takes time. And Rust deserves that time, especially if C features made their way into the kernel via GCC C extensions. If I were a company concerned about writing a Rust kernel driver or not -- I'd be way more concerned about the vicissitudes of more wild ass kernel maintainers, Linus, and the GCC maintainers, than whether Rust is going to stabilize any necessary items on the kernel team's list.
So, IMHO, yes, there may be some difference between GCC's extension stability guarantee and Rust's unstable (duh), depending on what you want, and how you want to look at it. But at 10,000 feet, this is a mostly lawyerly, but, trivial point.
Linus's position, as far as I've heard and ascertained, is that introducing any language into the kernel is going to require case-by-case and subsystem-by-subsystem analyses. He's not going to reject the language wholesale, but at the same time it's impossible for him to wholesale mandate its adoption. "Kicking maintainers in the ass" sounds great but nothing is ever that simple.
The only way I ever interpreted his actions so far is he's willing to allow those who want to try.
And I see nothing unreasonable and no failure in that. It is a hashing out process, in process.
"He approved" != "He wants"
However, I do wish he would say something publicly, so that the internet peanut gallery doesn't fill the void with negativity. It doesn't exactly help attract more interest in the project.
It's interesting that people expect Linus to simultaneously chill out and be more inclusive while at the same time acting like a dictator over the entirety of the project.
In any case, perhaps it's worthwhile to remember where it started, and what the attitudes were at the time [1]. It was an experiment. Experiments sometimes fail or reveal themselves to not lead anywhere useful. The choices were to let that experiment happen on the actual kernel or force the rust people to fork some version of the kernel and instantly be left behind.
It clearly wasn't an easy choice and I can only imagine the uproar from the rust community if he then did what you suggest today. So, that leaves us with the question, what if he's decided it's no longer worth it? What then should we do with a mostly failed kernel experiment?
[1]: https://www.zdnet.com/article/linus-torvalds-on-where-rust-w...
It's not particularly interesting that different people have different expectations on different issues
In other words, there are clearly politics involved, so perhaps that should be taken into consideration before making a blithe point about a complex human organizational issue?
It is not really a good experiment in technical qualification nor in developer collaboration, if the leadership lets individuals to constantly blockade work, isn't it?
How else would you target them? You can disagree over tone and scope but this is an open source project with an open contribution model.
> publicly demeaning. Linus was like that. No sane developer wants that.
Show me someone who hasn't been turned to this behavior over frustration. In isolation you can always find this from a leader what you should be concerned with is context and persistence. While it was occasionally over the top the majority of the time he was perfectly "sane."
> A true inclusive environment also requires leaders to tell rowdy maintainers calling people "cancer" to know their place and watch their tone.
This is open source. What exactly is "their place?" How much time should one dedicate to policing tone? Isn't that personally targeting people but in a different direction?
Which is part of my point here. Previously we just developed and ignored Linus' hot head behavior. This push for a vaguely defined "truly" inclusive community is what I feel led Linus into the mistake of allowing Rust into core.
> if the leadership lets individuals to constantly blockade work
What if the work just isn't very good or is counterproductive to the project as a whole? What if there is no consensus on this point? How much time should one dedicate to building consensus?
>Thinking of literally starting a Linux maintainer hall of shame. Not for public consumption, but to help new kernel contributors know what to expect. >Every experienced kernel submitter has this in their head, maybe it should be finally written down.
https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...
>If shaming on social media does not work, then tell me what does, because I'm out of ideas.
Hector Martin went way beyond being a "prick". And Linus Torvalds told him to stop it.
Have you considered that the problem may be the people that are making "hall of shame" lists of people and doing social media brigading?
Worsening matters, Steve Klabnik (major Rust community figure, has run @rustlang, primary author of the Rust Programming Language Book, former Rust Core member, and moderator of r/rust), have been busy here and on reddit making excuses for Hector Martin. What kind of community is the Rust community?
I haven’t been involved with the Rust Project for years, I speak only for myself.
I said that I feel for Hector, he’s clearly hurting, and that I hope he feels better. I’ve said I don’t want to pass judgement on if what he did is right or wrong, because I’m trying to stick to facts here. I’ve said that I don’t think what he did was particularly effective.
That’s not making excuses. Hector’s actions aren’t the main point of this story. It’s not even his patch!
Where was this done? In the recent mailing list, the maintainer never called people cancer, he said
https://lore.kernel.org/lkml/20250128092334.GA28548@lst.de/
>And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
Not referring to people. And many developers would agree that a multilanguage codebase can easily end up becoming a nightmare and pure cancer to maintain, whether or not Rust is one of those languages.
Another C project has not had good experiences with all interop attempts, pulling the plug on interop with one Rust library, while keeping support for two other Rust libraries.
https://daniel.haxx.se/blog/2024/12/21/dropping-hyper/
>Before this step, we supported three different backends backed up by libraries written in rust. Now we are down to two: rustls (for TLS) and quiche (for QUIC and HTTP/3). Both of them are still marked experimental. >These two backends use better internal APIs in curl and are hooked into libcurl in a cleaner way that makes them easier to support and less of burden to maintain over time.
He said he now tries to be very clear about what he doesn't want. So I guess he is ok with how things are going, otherwise, we would be likely to see another of his famous rants.
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.
It says:
> For other matters, please feel free to contact the maintainers via email.
Which links to https://docs.kernel.org/process/maintainers.html#rust which has a list of people.
There is also https://github.com/Rust-for-Linux/linux/blob/rust-next/MAINT... which is the in-tree documentation of who maintainers are.
> The fact that this has to be specified - and still qualified with "most" - is a big part of the problem with this.
For a very long time, linux wouldn't even compile with clang, becuase they use gcc extensions. These are effectively the same idea as nightly features. The kernel has never used standard C. Nowadays clang has enough support and keeps it going.
I agree with you that I personally would much prefer that they were on 100% stable Rust, but the Linux folks in general are way more fine with depending on specific versions for the build.
I don't see rust taking over C in kernel ever.
re: broken rust builds
You should think very very hard on when it can break and how it effects C side of things.
The two things that putting Rust in Linux actually requires of existing C maintainers is:
- They have to not get in the way of Rust bindings
- They have to document critical pre- and post-conditions of their code that impact memory safety
That last one is a problem - not one that Rust caused, but a problem that's been in Linux nonetheless. This is the thing that all the BSDs hate on Linux for. Typically, the approach to handling big breaking changes with Linux kernel objects is "make it compile, then change all the things that crash until they stop crashing". This means there isn't any documentation to write safe bindings for any Linux kernel function, since it could, say, rely on you calling three other functions in a specific order that just so happens to match the one major driver that uses that subsystem[0]. For Rust bindings to make sense and actually provide value, the subsystem maintainers need to provide documentation that they usually don't bother with.
The first one on the list is the reason why Hector Martin ragequit his maintainer position and decided upstreaming Asahi drivers isn't worth doing. There's a few subsystem maintainers that internally decided "I don't care what Linus thinks, fuck Rust". One of them happens to be the maintainer for the DMA subsystem, which happens to be... fairly critical to writing any non-toy driver.
The problem is specifically that there isn't a push for Rust. Linus is uncharacteristically fence-sitting here, to the point where people are writing Rust drivers that can't be upstreamed because his own maintainers are blocking them. Having the kernel support two languages is fine, but it requires Linus actually put his foot down and either say "stop treating the Rust people like Nvidia and let them write safe bindings to kernel internals," or, "we're not going to do Rust at all because of X, Y, or Z."
[0] I am told amdgpu is like this.
What are you talking about? I'm yet to work at a business where developers aren't proficient in 2 or more programming languages. Why do you presume that experts in the field would be blocked by a limitation that does not apply to the vast majority of professional software developers?
Comment you're replying to is about some kernel developers not wanting to learn/write/use rust.
That is probably true.
The reasons for Rust are compelling. And the uncountable value of the Linux kernel justifies a lot of pain.
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]."
Anyway, some slides at a conference are not the authoritative source for who works on Rust in the Linux kernel, something this is:
grep -i rust MAINTAINERS
Currently feels like you need a PhD in programming languages to use it effectively. Feels like Haskell in many ways.
Rust got popular in part because it made systems programming easier, simpler and more fool-proof than the existing alternatives (C, C++) for those coming from languages like Python, Ruby and Java. As someone whose primary experience is in Python, I never found Rust abnormally difficult to pick up, whereas Haskell is (and remains) entirely alien to me. Sure, lifetimes can get messy, but it's much easier to have the compiler hit me on the head when I'm doing something dumb than to spend 2 days figuring out how to use Valgrind and the other half-dozen different static analyzers. I don't need to devote 100% of my mental effort to be able to write reliable code that's not going to blow up later in subtle ways.
I've learned it because it was easier than C++ or even C. Yes you can learn C quickly, but you need much longer time than for rust to use it properly.
Also I do not have PhD not even CS degree and it was not hard. You should try it.
Rust is also quite stable and mature by now, I'm not sure what example or reason you're using to say otherwise.
> 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...
Rust's 2024H2 and 2025H1 flagship goals are about getting Rust for Linux into stable Rust, implementing features we need and so on. We really appreciate being a flagship goal of theirs! We collaborate regularly, and some members are part of both projects, and so on and so forth.
But that does not mean one is driven by the other, just like GCC and Clang do not drive the Linux kernel because they introduced features to build it. They support us, which is different.
> Also, didn’t the author of this updated doc (Miguel Ojeda[1]) resign from R4L? I’m not sure what his role is here.
I wrote the document, but I never resigned since I started the project -- you are probably referring to Wedson. I have seen articles that confused both of us in the past, so that is not a surprise, though I wouldn't mind to have Wedson's mind around from time to time :)
The FOSDEM 2025 keynote has some details about the history of the project. There is an LWN article about it: https://lwn.net/Articles/1007921/
I hope that clarifies.
I don't understand what you're saying - is your point that having Goals means that this can no longer be considered a hobby? Lots of people have hobbies where they have goals for a sense of direction and satisfaction. (Not to mention that the page doesn't say it is a hobby, just that it was started as one.)
> Also, didn’t the author resign from this effort before? Or was that departure not as dramatic as I recall.
Who do you mean by "the author" here? This seems to be a group effort by a "Rust for Linux" group, not a single individual.
[1] https://rust-lang.github.io/rust-project-goals/2024h2/rfl_st...
It's up to the awesome Rust for Linux folks to work on the integration and upstreaming and policy needed to ship the kernel with Rust. And they're doing incredible work, based on the ability to write more and more kinds of drivers/filesystems/etc in Rust.
It just seems very aimless and unfocused.
The vast vast vast majority of Kernel development (and, I would guess, low-level open source software development) is paid for by companies.
Here's an example. Scroll down to "Most active 6.13 employers". Unknown+None is not even 15%: https://lwn.net/Articles/1004998/
From my understanding, the current maintainers are worried about being stuck with Rust code should the Rust maintainers leave the project, and Linus is requiring that all code builds that makes it into a release (which includes the Rust code).
I am not for or against Rust being in the kernel, but I can appreciate the view of maintainers on a project of this age being concerned about introducing a second language (one which many of the C developers are not familiar with). This isn't a single company's web application project where a polyglot environment should work well when chosen for the right reasons. The Linux kernel is a backbone of modern computing, and making a decision on what to do without exploring all potential benefits and issues would be irresponsible at best. From what I've read, the Rust proponents want a piece of Rust middleware for DMA access so that each rust component doesn't need to have their own implementation, but the C maintainers don't wish to have to maintain C interface compatibility for Rust. With Linus stating that all code in the project must compile to be accepted in a release, this puts a heavy burden on the C maintainers where they are now required to work with the Rust developers fairly closely. Some of these maintainers have been around for a long time, and are skilled in C and do not wish to learn a new language for when the shit hits the fan and something in the Rust code breaks.
Again, this is just my understanding of the situation from what I've read, I may have some of this completely wrong, and if so I apologize to anyone involved.
This does not seems like arguing in a good faith. As example last 'drama' was explicitly about that PR with Rust code went into Rust branch not under C maintainer. Yet he blocked it anyway even when Rust maintainers stated, again, that any change in C API, that would break Rust code, was responsibility of Rust maintainers. Yet people (like you) are still ignoring this. Why?
Subject: Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction. https://lwn.net/ml/all/20250108135951.GA18074@lst.de/
I believe there is a middle ground where everyone can be happy, and firmly believe that the Rust maintainers in the Linux project will keep on top of the C interfaces to know when there will be changes. Going back to my comment, I realize that I presented why the C developer/maintainers don't want Rust, but that is not my own stance. In my opinion, there is enough interest in the Rust for Linux project that acting as though there is only a single maintainer, and if they disappear the entire project fails and all Rust code stops compiling is unrealistic and FUD.
I can see a whole host of problems being tackled, especially in driver development and safety concerns, by using Rust. I feel the C maintainers are acting as if the entire kernel is going to be rewritten in Rust in a timeframe where any of these people would still even be capable of using a keyboard or not suffering from severe dementia.
My apologies to anyone that thought I was pushing for one side or the other, I was only repeating the recent "drama" that I heard was going on, and I respect both sides.
Writing policies hard, and the environment here is somewhat challenging.
No. Better to have just Linus for Rust. Write a new OS in Rust unencumbered by C curmudgeons. As a bonus it won't be thankless but pretty exciting project on work on.
The problem with this direction is it dooms Linux to obsolescence. Thanks to Rust's memory safety, Redox has achieved a level of security and crash-resistance that Linux cannot hope to achieve with C. With everyone (including the US Govt) pushing for memory safe code, this has a negative impact on the whole world's major investments into Linux.
To mitigate the sunk costs, Linux needs to compete on memory safety. C has no viable solution so Rust is the only option.
Isn't Zig designed as a viable solution? IIRC being easily compatible with C is one of its features.
The right call here is to tell Ted Ts'o and the other old guard that they need to adjust to the new Rust reality, because things like being explicit about object lifetimes will make the C code better as well as more compatible with what the Rust side wants to do. But he either doesn't want to do that or is looking for a diplomatic way to go about it.
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?
Linus will retire and leave the Rust mess for other to live with.