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.
> 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).
> 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.
IMO you're comparing apples and oranges. The GNU C extensions are 'stable' when using GCC, they're just not part of the regular C language, plenty of them are still in wide use in the kernel. Unstable Rust features in comparison are explicitly in a state where they could be changed/broken or removed in any later release.
You're not wrong, but at this point, there's close communication between the Linux folks are the Rust team, and the Rust team has committed to stabilizing things that the Linux team needs. There is basically no chance that suddenly one of the core things they need is going to disappear. They've already gone through the list and checked that it's all stuff that is eventually going to land.
> Unstable Rust features in comparison are explicitly in a state where they could be changed/broken or removed in any later release.
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.
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.
To play (BDFL's) advocate - Linux is an -enornous- project. It's not physically possible for any effort to be unilaterally directed. Linus does not personally maintain the whole thing, it's just not possible. So he has maintainers under him who are in charge of the subsystems - the implication being that he trusts their judgment and technical expertise. There's no other way the system could work, really.
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.
I think this is an important point. People believe "dictator" means "complete control" when instead "dictator" mean "authority to make any decision." The difference is exactly what you say, that you still have to rely on the hierarchical structure and trust that your "underlings" are making the right decisions. Complete control doesn't scale very well and even a small project or team has many moving parts and the only way to have full control is to be involved in every part. With scale, rapidly comes the necessity for trust. There's only so much time in a day, and only so much can be done in an hour. Damned physics, always getting in the way.
Either he failed at communicating, or he does not care. Reading the recent thread/flamewar on R4L and DRM I wonder if he was somewhat pressured to accept Rust but does not actually care. If you were the leader of a project and explicitly authorized a sub-project, would you tolerate a maintainer undermining it?
FWIW, there are plenty of backchannels through which discussions about this stuff can be had that aren't the public mailing list. My limited understanding is that those discussions have in fact taken place and the R4L people aren't concerned about things working out eventually.
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.
I don't know enough to agree or disagree with the person you're replying to. But I assume the logic would be that if Linus doesn't approve then he should have shut the discussion down long ago or at least do it now without half measures
> then he should have shut the discussion down long ago
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?
> 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.
It's not particularly interesting that different people have different expectations on different issues
It's interesting that you moved the goalposts to an entirely different point. I'm clearly talking about the overall "community," which whether you care about it or not, has been used as a point to successfully force Linus' hand before.
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?
You can be decisive and inclusive without being a prick who is personally targeting developers and publicly demeaning. Linus was like that. No sane developer wants that. A true inclusive environment also requires leaders to tell rowdy maintainers calling people "cancer" to know their place and watch their tone.
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.
>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!
I'm not gonna end up replying to this thread again, because it's a waste of my time. But I will elaborate on some things.
> You have clearly made excuses for Hector.
This is how posts like this use semantic drift and context collapse. Take this for example:
> Against the decision that the project made, that is very straightforwardly sabotage.
I can believe that the definition of the word "sabotage" applies in this situation without supporting every last thing about Hector and his actions. But because Hector is originally the one who said this, you turn my specific statement into some sort of generic "making excuses."
Also, the first and third comments have nothing to do with Hector. The fourth one is just stating some facts?
> And how can you not deem it wrong of him to begin social media brigading?
Because this is also making a mountain out of a molehill. Hector complained on Mastodon about something that was happening. He was very clearly burned out and upset.
Do I think it's good? No. Do I think it worked? No. But I'm not particularly interested in trying to pass some sort of judgement about if Hector is Good or Bad simply because he said a bunch of things when he was at his whit's end. If I did, I would be quite the hypocrite.
Notably, I also am not interested in passing judgement on weather Christoph Hellwig is a Good or Bad person.
None of this is about that. I don't know either of these people. They could be having a bad day. Or maybe one or both of them are evil. I don't know and I don't really care.
> How can you not deem it wrong of him to begin making a "hall of shame" list?
I don't use mastodon, and so I didn't really see this follow-up. I'm aware it exists, but not of what's in it or what it's about. Maybe it sucks. No clue.
> If it is true that you, Steve Klabnik, were "Community Team Leader for the Rust team at Mozilla, in charge of official Rust community documentation as well as the key Rust community advocate.", can you confirm that you were in the past paid to be an advocate for Rust? And if yes, are you still paid to be an advocate for Rust?
Listen man, if you want to play Joseph McCarthy, be my guest, but I'm not going to engage. It doesn't really matter what I say.
>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.
>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.
I remember seeing an interview where Linus said that at one time, he rejected a contribution and felt bad because he wasn't clear enough in that he didn't wanted that.
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.
Exactly. The recent DRM issue was about who's time would be wasted. Rust is either happening, and they are wasting time by not having proper bindings, or it is not, and all the drivers written were a waste of time. In either case, the discussions around it are already a waste of time.
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.
> 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'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?
Internal or external, it doesn't change much. Either Rust usage remains very isolated, or Rust takes Linux over and who doesn't want to deal with Rust should leave. Even the policy acknowledges, that the rust team being responsible for fixing broken rust builds is only temporary.
Rust was specifically designed to integrate well into a C codebase; and Rust for Linux was specifically for drivers - not to replace all of Linux's internals.
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."
> Sources requested. I don't even know why you'd claim this.
I think the original quote is most favorably interpreted in comparison to other languages with a runtime that require external C code to know its calling into another language (for example, Python with manual calls to increment/decrement refcounts).
One of the reasons Rust dropped its original runtime was specifically to allow it to "pretend" to be regular C code - if you build it to be consumed as a C library external C code can use it and be none the wiser that it is calling into another language.
There's also other affordances for playing well with C (extern "C", no_mangle, #[repr(C)], etc.)
In that sense, Rust is indeed specifically designed to play well in C codebases as the rest of the C code can basically pretend it's only working with C code.
> 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.
I'm not sure that example is particularly relevant. At least at a high level it seems the primary reason the hyper backend was removed was because of a lack of interest rather than some innate issue with Rust interop. If anything, the continued existence of the other two Rust backends would seem to hint that Rust interop is not really that much of an issue.
>In that sense, Rust is indeed specifically designed to play well in C codebases as the rest of the C code can basically pretend it's only working with C code.
Do the semantics of the borrow checker play nicely with C projects, depending on architectures? And the other semantics of Rust?
>When we started this, even rust itself was not ready and over this time rust has improved and it is today a better language and it is better prepared to offer something like this. For us or for other projects.
>It takes someone who is interested and good at both languages to dig in, understand the architectures, the challenges and the protocols to drive this all the way through.
>I am not against revisiting the topic and the idea of providing alternative backends for HTTP/1 in the future, but I think we should proceed a little different next time. We also have a better internal architecture now to build on than what we had in 2020 when this attempt started.
If the above quotes are accurate, how would it be consistent with what you wrote?
>In that sense, Rust is indeed specifically designed to play well in C codebases as the rest of the C code can basically pretend it's only working with C code.
This quote especially:
>It takes someone who is interested and good at both languages to dig in, (...)
As for being designed for interop with C, I found this blog:
Where they chose Zig instead of Rust, and mentioned the importance of interop, and that Zig also is a C compiler. Something that is claimed on Zig's website as well:
>Incrementally improve your C/C++/Zig codebase.
>
>Use Zig as a zero-dependency, drop-in C/C++ compiler that supports cross-compilation out-of-the-box.
I know barely anything about Zig, so I don't know the veracity of this, however.
Borrow checker semantics only apply to Rust, not C. When you write the bindings you're also responsible for mapping the C code's preconditions and postconditions to something the borrow checker can understand.
For example, the semi-common pattern of reference-counted objects sitting behind opaque pointers would call for a transparent wrapper type around a bare pointer, with appropriate implementations of Drop and Clone to decrement and increment the reference count, and inlined wrapper methods to call any C methods associated with the object.
You can, of course, call C directly without worrying about writing any of those types; but now you have to write a bunch of unsafe blocks to call those functions all over your non-binding code. This isn't great. In fact, that's basically the underlying argument surrounding R4L right now: the Rust people want to write nice Rust bindings that let the borrow checker do the work, while the C people[0] want Rust to just call C directly. To be clear, both approaches have the same runtime performance, the only implication is on whether or not Rust will be able to verify correctness of the code.
The unsoundness you mentioned specifically refers to taking variadic arguments when called from C, which are a bit of a hack even before you talk about Rust interop. In ISO C, you have to call va_end in the current function, with the current stack frame. Rust's compiler doesn't guarantee that Drop implementations are inlined, so your code might wind up calling something else that calls va_end, which isn't good enough. However, this is a moot point, because LLVM/clang treat va_end as a no-op and thus can't get screwed up by Rust not following ISO C spec. I doubt LLVM is going to add optimizer passes specifically to break code that uses va_end wrong if they aren't even using it themselves. If they did, rustc could be modified specifically to support forcibly inlined Drop, just for std::ffi, if needs be. It wouldn't break any code to add this. In other words, it doesn't matter unless you're trying to make Rust code link with, say, stuff compiled by ancient C compilers like Metrowerks CodeWarrior[1] or something; and that stuff makes use of varargs.
As for Zig, I haven't used it. I trust that it also has good interop facilities. But that doesn't matter since we're talking about Rust for Linux, not Zig for Linux.
[0] Or at least the ones willing to entertain a multi-language Linux
[1] I have no clue if that compiler ships a va_end that depends on being called in the current stack frame or not.
>In fact, that's basically the underlying argument surrounding R4L right now: the Rust people want to write nice Rust bindings that let the borrow checker do the work, while the C people[0] want Rust to just call C directly.
But the bindings still require expertise in both languages to write, don't they? And knowledge of both codebases?
And I haven't followed the specifics of the mailing list debate closely, but couldn't the nice bindings be copied or vendored into each Rust driver or something? I could be wrong, and it wouldn't be neat at all, and be a lot of bloat, but would enable having bindings. Some people argued the Rust code could be maintained out-of-tree, like some other projects were, even though it would take extra effort and also probably require tooling and processes.
>In other words, it doesn't matter unless you're trying to make Rust code link with, say, stuff compiled by ancient C compilers like Metrowerks CodeWarrior[1] or something; and that stuff makes use of varargs.
I did mention that it might not be an issue in practice, given some assumptions. However, if LLVM changes, or if for instance the Rust standard library is reused or copied over to GCC Rust, then the code would need to be changed. For GCC Rust, I wonder if part or all of the standard library could be forked, to have a GCC specific Rust standard library implementation, similar to what happens with C++'s standard library.
>As for Zig, I haven't used it. I trust that it also has good interop facilities. But that doesn't matter since we're talking about Rust for Linux, not Zig for Linux.
Sorry, but it does matter, since claiming that a language like Rust has good C interop of course leads to relative comparisons with other languages in similar spaces and how well they do relative to Rust. And if the promises by Zig holds, and the experience people talk about with Zig holds, then Zig appears to have a substantially better track record in regards to C interop than Rust. Which isn't surprising, since Zig is a less advanced and more primitive language than Rust, and while that has drawbacks, it can also have benefits, possibly like in this case with having much better C interop than Rust. In the same vein that the interop between Rust and C is likely way better than (unless confined to the C subset) the interop between Rust and C++.
> Do the semantics of the borrow checker play nicely with C projects, depending on architectures? And the other semantics of Rust?
I don't see why the borrow checker and other Rust semantics are relevant in this context. As the sibling comment stated, if you're writing Rust code that is intended to be consumed by C code you're going to be writing a C API, which almost certainly entails mapping Rust semantics to C semantics and vice-versa so what you expose is what other C code can understand (i.e., you're not exposing anything Rust-specific). Sure, that might require the calling C code to do some work on their end to uphold invariants, but that is not exactly an uncommon requirement when writing C in general.
> If the above quotes are accurate, how would it be consistent with what you wrote?
Well, first of all you're stripping context from the bit you quoted from me. That statement was contrasting Rust's C interop with languages with runtimes which require the consuming C code to be aware of the fact that they're calling into a different language and require additional boilerplate to do so - messing with refcounts in Python, JVM-specific types in Java, so on and so forth. In this context, the quotes you picked out are basically irrelevant as they are about entirely different topics.
But in any case, let's try to look at those quotes from the article anyways:
>When we started this, even rust itself was not ready and over this time rust has improved and it is today a better language and it is better prepared to offer something like this. For us or for other projects.
"Rust was designed to play well in C codebases" is not inconsistent with "Rust's C interop can be improved".
Unfortunately it's been hard to find exactly what Rust changes have been driven by this work, but at least based on the initial announcement of the hyper backend experiment [0] it seems that the improvements to Rust are less about the language's C interop and more about dealing with error handling/OOM. An important issue indeed, and one that is still being worked on, but distinct from language-level C interop nevertheless.
Put another way, there would be similar issues if someone tried to add a C backend which aborted on OOM as well. It's not "Rust doesn't play well with C", it's "this development style doesn't match the one we want/use". That is language-agnostic.
>It takes someone who is interested and good at both languages to dig in, understand the architectures, the challenges and the protocols to drive this all the way through.
I can't say I understand your focus on this quote. There's no inconsistency between this and what I said because this quote says nothing about how well (or not) the Rust code works with the rest of the curl codebase. The quote would apply basically verbatim to C++/Zig/D as well and those have nearly seamless C interop.
>I am not against revisiting the topic and the idea of providing alternative backends for HTTP/1 in the future, but I think we should proceed a little different next time. We also have a better internal architecture now to build on than what we had in 2020 when this attempt started.
Similar thing here.
> As for being designed for interop with C, I found this blog: <link> Where they chose Zig instead of Rust, and mentioned the importance of interop, and that Zig also is a C compiler. Something that is claimed on Zig's website as well:
Zig does indeed have very nice interop with C. However, that's irrelevant in the context of this conversation - the fact that Zig (or other languages like C++ and D, for example) is better at C interop than Rust has literally zero bearing on whether Rust was designed for interop with C.
> Rust's FFI also relies on undefined behavior if this comment isn't outdated
I'm not sure the comment isn't outdated, but in any case I think the sibling comment addresses this better than I could.
This is one of those things where I suspect the current behavior is good enough given current manpower/resource constraints and would be reprioritized if it ever becomes an issue.
When Mozilla sponsored Rust development long ago, it was to eventually include Rust code in Firefox. That’s C++, not C, but C is easier than C++ in this regard.
My sibling is also correct, language decisions were made in order to keep FFI zero overhead.
Just because it didn’t work out for one project (and really, one part of that project, one out of three parts) doesn’t mean it never works for anyone. There’s a lot more projects where it has.
> 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?
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?
Every other engineering organization on the planet seems to do just fine with a polyglot codebase. Do you really think kernel maintainers are dumber than the average Google engineer?
I can't image what reviewing C code like that would look like? Rust is a complex piece of technology, is the transpiled C code 'clean' enough to be able to review it?
It doesn't, because C code is clearly "the preferred form for modification" by C kernel devs that, by their own admission, are quite unwilling to deal with the perceived complexity of a multi-language code base. (Or even to learn any other programming language, for that matter.)
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]."
Would YOU want to be named (without permission) in a document like this as being responsible for something in a high-visibility project like the kernel just because you contributed some code, or gave a talk at a conference?
Anyway, some slides at a conference are not the authoritative source for who works on Rust in the Linux kernel, something this is:
The question of who has the authority over the policies regarding the integration of Rust code into the kernel seems like a different question than who is maintaining Rust code.
I think the way it was handled is pretty reasonable considering it's a public facing statement. Putting your name down on an authoritative statement is an important commitment internally, but a name put down for any reason on a public statement is a magnet for a firehose of questions, controversy, and potentially harrassment.
With all due respect I question how much experience you actually have with Rust. It's nowhere close to being as difficult a language as you describe.
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 feel crazy when I read comments like that about Rust. C is much, much harder than Rust. C is absolutely crazy difficult. Fairly simple to learn, but incredibly hard to actually write correctly. Rust is much, much easier. The learning curve isn't that hard. One week and you can be fairly productive with it.
I'm not sure lowering the barrier to contribute Linux kernel code is a great argument for C. It sounds like contributing code that doesn't segfault often still requires a PhD.
Rust and Haskell are completely different languages so I don't really agree here. Haskell doesn't have the features (lifetimes, ownership) that make Rust "hard" and Rust lets you have mutable states and procedural code.
Rust is also quite stable and mature by now, I'm not sure what example or reason you're using to say otherwise.
I agree that rust is much less difficult than C++. But the things that are difficult about Rust are also difficult about C++… just less difficult, because the compiler helps you with them.
> 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
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 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.
That makes it much clearer, thanks. There might be some quibbling over the wording of the goal and whether this technically counts as RFL being driven by the Rust Project, but the goal page [1] is at the very least a clear statement of the incentives they have to push for RFL, in their own words.
As Miguel said, the commitment from the Rust project is making Rust for Linux build on stable Rust, rather than using nightly. We care about that for a variety of reasons: we don't want folks to get a negative impression of Rust's stability based on nightly Rust, and Rust for Linux is a good exemplar of projects needing certain features, and it's an important effort in its own right that demonstrates the ability to incrementally add Rust to an established project.
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’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.
I personally think Linus is making the right choice here, and not explicitly denying Rust in the kernel. Instead he is delegating it to other high level maintainers to work out the issues and make the decisions on how the integration will go. He is already so heavily involved in day to day operations in the C code, I can't imagine him being able to take on the burden of also needing to negotiate pulling in an entirely new language.
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.
> 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).
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?
Please see this thread, which is where I got my information from. If you have a better source, I would love to read it. I understand that you may be passionate about wishing to have Rust in the kernel, but I was not fighting for or against this. To claim that I am not arguing in good faith (I am not arguing), and then to say that I am ignoring what you've said is the actual argument in bad faith. I also stated to correct me if I'm wrong, but I will believe this thread over a comment that seems to be more emotion over fact (as I fail to see how I ignored anything, and made no claim to be an expert). I would love an actual conversation over this, but only in actual good faith.
I probably didn't describe myself well enough. I was under the assumption that there was a Rust middleware to interface with the C API, and some of the C maintainers objected even to this because they feel they will need to be in communication with the Rust maintainer(s). I am not against Rust being used alongside, or even in the kernel. I was just pointing out some of the objections the C developers were stating.
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.
It's not that it's volunteer driven (which it is not, as the siblings have pointed out), it's that it's distributed governance without the central authority enforcing a vision.
Most development in this space (toolchain and kernel) is funded in some way. I don't know if this particular project is at some strange intersection where this isn't the case, but I would be surprised.
Writing policies hard, and the environment here is somewhat challenging.
I agree it’s no easy task. It seems to me though, as an outside observer, that writing virtually no enforced policy is the lazy way to go about it. Write a policy, stick to your guns, have a procedure for changing it if you get it wrong.
The people who contribute to kernel and especially maintain the subsystems are some of the most well-paid developers out there. If they are not a principal engineer somewhere, they have their own lucrative consultancy business.
My guess is someone needs to step up and be the Linus of Rust code for Linux. It's the kind of thankless task that is invaluable, whoever can muster the courage to do it will be vital to Linux/Rust.
> someone needs to step up and be the Linus of Rust code for Linux
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.
OS part is easy, there's an OS behind every other sofa in your closest university with software engineering classes. Getting people to write drivers for it is the hard part. Most OSes never boot outside of qemu.
Such new OS exists already (Redox). It's actually really good and can run modern DEs (Cosmic) and some recent commercial games (Balatro).
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.
Probably depends on what exactly you're looking for in a viable solution. Zig does not provide the same level of memory safety as Rust does (IIRC it doesn't protect against data races and doesn't offer (complete?) temporal memory safety), so if what Rust provides is the bare minimum you want Zig won't cut it.
Despite starting off "not big and professional like gnu" Linux now has trillions of dollars' worth of business going over IT infrastructure based on it. You bet your ass it's a corporate funded behemoth now, not unpaid volunteer driven. And with corporate money comes corporate governance. Ouster of Linus as the chief maintainer is definitely on the table (though not likely to ve exercised here and now). I think Linus is being wishy-washy so as not to anger either the traditional "C-niles" currently holding the kernel together or the Rust group, who are likely a more prolific source of new development.
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.
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?
I think it was Kurt Vonnegut who said If Rust for Linux died horribly due to a maintainer meltdown, it will not have died in vain. It will have entertained us.
Rust is easier to learn than C. Specifically, the things that are hard to learn in Rust are things that C will stab you in the back on.
The biggest problem with C is having to manually track memory ownership and usage - i.e. who can call free() or dereference pointers without crashing the whole program. Rust automates that away, in a way that introduces no runtime performance overhead.
The problem with "C kernel wizards" is that the things they're good at solving are not part of the essential complexity of writing an operating system kernel. A lot of it is chasing use-after-frees or dangling pointers. Tedious manual work that absolutely can be automated away, but isn't, because forty years of C being The Only Systems Language You'd Dare Fit In A Kernel has made people just assume all its hidden complexity is essential.
Come on, managing memory in C isn't that hard. Yes, there are constant failures because many times people don't have a proper foundation in C memory management before they're allowed near the github commit bit. That's an organizational issue, not a language issue.
Rust does eliminate the issue, because it forces people to go through that foundational learning or their code won't actually compile! But C is also fine, if you know what you're doing.
"C is fine if you know what you're doing" is the "trust me, bro" approach to software engineering. Even experienced "C kernel wizards" make stupid mistakes. Also, nobody actually knows what a pointer is, not even the wizards; we keep learning new things about them every time someone finds a combination of optimizations that cause miscompiles[0]. For something as security-critical as an OS kernel, the correct approach is to have automatic verification - i.e. code can't stab you in the back if it can't compile.
See, I'm coming from the perspective that people who work with Language X have learned where all the dark corners of Language X are. Would you expect anything else? C does not have more dark corners than Python, Ruby, PHP, LISP, Rust, etc. Part of being an expert is knowing the language you're working with, and knowing the limits of your tools. When you update GCC and they add some bonkers optimization strategy that introduces new undefined behavior, you should know about that.
Even experienced "Rust kernel wizards" will make mistakes. You'll see.
If web developers can learn one language for a backend and one language for a frontend, I'm pretty sure those "kernel wizards" have the ability to learn a second language.
Assembly is unavoidable in the kernel and the the lowest level machine language and it closely related to C and is something that many C developers of kernel level capability are going to have some familiarity with.
Rust is none of those things. It is not required. It is a completely different language.
I’m just poking fun at the inconsistency in your argument. Rust is a lot closer to C than assembly is. Arguments that boil down to “I can’t figure out how to read this language” are stupid because we expect kernel developers to understand a far weirder language in their day-to-day work, one with significantly less high-quality material available to get up to speed on it, and often with semantics that are not even written down anywhere. I write more assembly than Rust these days and I’d choose the latter in a heartbeat if I had to review someone else’s changes.
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.