Behold, a Linux maintainer openly admitting to attempting to sabotage the entire Rust for Linux project:
https://lwn.net/ml/all/[email protected]/
The good news is this doesn’t affect drm/asahi, our GPU driver. The bad news is it does affect all the other drivers we’re (re)writing in Rust, two so far with a third one coming.
Another choice quote, calling R4L “cancer”: https://lore.kernel.org/lkml/[email protected]/
Personally, I would consider this grounds for removal of Christoph from the Linux project on Code of Conduct violation grounds, but sadly I doubt much will happen other than draining a lot of people’s energy and will to continue the project until Linus says “fuck you” or something.
As for how to move forward, if I were one of the Rust maintainers, I would just merge the patch (which does not touch code formally maintained by the dissenter). Either Linus takes the pull, and whatever Christoph says is irrelevant, or he doesn’t, and R4L dies. Everything else is a waste of everyone’s time and energy.
Edit: Sent in my 2 cents: https://lore.kernel.org/rust-for-linux/[email protected]/T/#m1944b6d485070970e359bbc7baa71b04c86a30af
A fanatic microblogger* inflating some kernel drama, and inviting the microblog echo chamber and the whole internet gantry to chime in… is surely worthy of being the hottest topic of the day.
* Yes, I know who they are.
The original entry from the mailing list this is all about:
On Wed, Jan 29, 2025 at 10:33:22PM +0100, Danilo Krummrich wrote: I accept that you don’t want to be involved with Rust in the kernel, which is why we offered to maintain the Rust abstraction layer for the DMA coherent allocator as a separate component (which it would be anyways) ourselves.
Which doesn’t help me a bit. Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this. This is NOT because I hate Rust. While not my favourite language it’s definitively one of the best new ones and I encourage people to use it for new projects where it fits. I do not want it anywhere near a huge C code base that I need to maintain.
I will do everything I can do to stop this.
I can see that this can be interpreted as a sabotage. If they are dressed like a clown. With a gun and a pack of sandwiches.
I think C should be used where its memory safety issues are not a big issue and can’t lead to private data leaks in an obvious way. But Rust seems to be a fine language. It just shouldn’t be abused or else we’re risking to lose the performance benefits of Linux.
You know as someone so far removed from kernel development as I am I have to say that Rust devs are the most annoying fanboys there are and ngl if this kills R4L I won’t even notice aside from those drama threads dissappearing. Just write your own Kernel in Rust if you must. With Blackjack and Hookers.
My feelings exactly. Somehow Linux has managed to achieve so much with C. And running on all the major cloud providers, running missing critical apps. Shit we have Linux and BSD in space, running long term missions successfully.
The rust cult constantly seems to demand integration with the Linux kernel and being toxic about it, while actually contributing very little to achieve the interoperability, demanding the kernel Devs sort it out, or else…
I’m not a dev, it’s just how a lot of this drama reads.
To me it feels like it’s the other way around.
I wasn’t even aware that people tried to establish multi-language drivers until I read about the cancer comment some time ago.
It’s not the first time that longstanding maintainers dislike new stuff because it’s new.
Everytime i read a transcript from kernel devs arguing i think it takes a day off my life.
Is it because you read one per day by the end of the day?
I am not a programmer. If you showed me C code and called it Rust, or vice versa, I would probably not be able to tell the difference. As such I’m not going to focus on technical merits or demerits, I’ll focus on what people say.
- [Danilo Krummrich] What does “your code” mean? Duplicated in every driver?
- [Christoph Hellwig] Yes, interfaces to the DMA API should stay in readable C code and not in weird bindings so that it reminds greppable and maintainable.
- [DK] Rust drivers shouldn’t use C APIs directly, but rather use an abstraction of the corresponding C API.
- [CH] Don’t force me to deal with your shiny language of the day.
- [DK] Again, no one asks you to deal with or maintain this piece of Rust code.
- [CH] Maintaining multi-language projects is a pain I have no interest in dealing with. If you want to use something that’s not C, be that assembly or rust you write to C interfaces and deal with the impedence mismatch yourself as far as I’m concerned.
- [DK] This is exactly what we’re doing and proposing here, isn’t it? // We wrote a single piece of Rust code that abstracts the C API for all Rust drivers, which we offer to maintain ourselves. // What else are you asking for?
- [DK] Since there hasn’t been a reply so far, I assume that we’re good with maintaining the DMA Rust abstractions separately. // Hence, the next version of this patch series will have the corresponding maintainer entry.
What I take from this interaction is that Hellwig is not really picking a bone against Rust; his main concern is introducing new languages into the kernel and reducing its maintainability. And IMO Krummrich’s answer up to the second-to-last reply was really great - addressing the complain by highlighting that C developers won’t need to bother with that chunk of Rust code. (That last reply was awful, though.)
Based on this interaction I think that I agree with 5714 in this thread, that Hellwig might be overreaching.
So far, so good. What Hector Martin is doing there is something else. He is not selling the merits of the project Rust4Linux, he’s simply creating drama, by distorting Hellwig’s position from “don’t bring new languages into the kernel” into some sort of personal crusade against Rust.
And it’s rather “curious” how he brings up the CoC as some sort of rubber stick to bash people with, but omits which part of the CoC Hellwig would allegedly have violated.
[@raulinbonn] @marcan He does use the proper name shortly afterwards, but calling it “the another language” instead of just Rust sounds already quite loaded and belittling really. As if trying not to even acknowledge its proper name and existence.
Relevant tidbit: “the another language” sounds like a word-by-word translation from German “die andere Sprache”. It doesn’t really sound dismissive in German (Hellwig is clearly a German speaker.)
“As if trying not to even acknowledge its proper name and existence.” - okay… now the user is assuming = making shit up. It’s perfectly possible that Hellwig simply didn’t call it “Rust” to focus on the fact that his problem is not against Rust, but against a mixed language codebase - the complete opposite of what raulinbonn is assuming.
don’t bring new languages into the kernel
Didn’t the guy who decides on bringing new languages to the kernel(that’s not Christoph Hellwig) specifically said “do bring Rust to the kernel”? And bringing it to the drivers not core subsystems is exactly because C developers won’t need to maintain it?
Hector Martin isn’t claiming that Hellwig’s crusade is against Rust, but against R4L. The problem is that the R4L project has always been about Rust in the kernel. “Don’t bring new languages into the kernel” is a crusade against R4L.
Hector Martin isn’t claiming that Hellwig’s crusade is against Rust, but against R4L.
Fair point.
“Don’t bring new languages into the kernel” is a crusade against R4L.
Still neither a crusade nor a personal one, unless proved contrariwise. It’s just that he’s prioritising some things and the R4L project is prioritising other things.
I didn’t use the word “personal”, but it’s inherently somewhat personal in that it’s one person trying to fight back against a decision that Linus and GKH have both endorsed (to put Rust in the kernel). “Crusade” is strong wording, but so is “I will do anything I can to stop this.” That’s far beyond simply “prioritizing [other] things.”
I’m aware that you didn’t use the word “personal”; I did. (Sorry if what I said implied otherwise, it was my bad.) My point is that Martin is making a big deal like Hellwig had some bone to pick specifically against the R4L project and Rust, you know?
Based on the info that I currently have at hand I do think that the project will progress further, against Hellwig’s wish, and this will be a net benefit for the kernel. I just don’t see the big deal that people make of his opposition, he’s just being the old man screaming at cloud.
But…that’s exactly what’s happening. Rust is already in the kernel, with both Linus’s and GKH’s approval. CH is trying to singlehandedly reject any use of Rust in any part of the kernel where he has maintainer status. That’s pretty specific to R4L.
“How dare anyone criticize rust” is what this boils down to
Christoph Hellwig isn’t criticizing Rust the language, and Hector Martin isn’t claiming that he is. This is about a project, Rust for Linux, that has been endorsed by both Linus and GKH, and one maintainer personally attempting to stop it from moving forward.
He did call it a “shiny language of the day”. That’s criticism. He’s saying the popularity of Rust is due to temporary hype rather than because it is intrinsically good.
Your position is entirely reasonable and an excellent example of how ignoring technical details leads to failures of technical leadership. C is one of several languages notable for extreme lack of memory safety. Its lack of safety has been repeatedly quantified; I like to recommend Gaynor 2021 for a high-level introduction. Rust was introduced primarily to replace C (and a relative, C++) and improve the overall security of computing systems.
The “merits of the project Rust4Linux” are simple and obvious: as code is translated from C to Rust, its overall characteristics (readability, performance, low-level modeling of machine behavior) will remain, but overall memory safety will increase. Opposition to it is reactionary, not well-grounded in technical merits; most of Linux is not well-proven to be correct, only believed to be correct under typical operating conditions as estimated by several dozen experienced programmers, and any technical options for improving our confidence in its correctness should be considered.
Also, finally, I have to dock you for reading comprehension. Martin was quite clear: calling Rust a “cancer” – a cute pun given Rust’s crab mascot, or a dehumanizing slur, who knows – was, to them, a violation of the Code. It is not difficult to read the Code and notice that, were it a slur, it would violate the prohibition on “insulting/derogatory comments, and personal or political attacks.”
Your position is entirely reasonable and an excellent example of how ignoring technical details leads to failures of technical leadership.
That’s why I didn’t address the technical merits, like a leader should. (Nor I am a leader; I’m a random with a chimp avatar.) I focused on the “popcorn” / drama.
[ Rust info dump ]
Cool beans.
What I’m saying is that Martin should be sharing this info, instead of creating drama.
Because ultimately the goal of both sides is the same, a better kernel. It’s just that one prioritises consistency (for the sake of maintainability) and another the advantages of Rust over C, and those priorities are in conflict.
And if Hellwig cannot be convinced, the leadership can, and should.
Also, finally, I have to dock [to reduce wage from; to deduct points from] you for reading comprehension. Martin was quite clear: calling Rust a “cancer” […] was, to them, a violation of the Code.
I’m saying that Martin has the moral obligation to make his complain as precise as possible: “The CoC says [insert excerpt] and Hellwig is going against that”. Telling people to RTFCoC is the opposite of that. Is this clear now?
Also, this either is or isn’t a violation of the CoC. There’s no space for “to them”, rule violations should be handled as objectively as reasonably possible. (From a quick check, it doesn’t seem to be one. I might be wrong however.)
a cute pun given Rust’s crab mascot, or a dehumanizing slur, who knows
There’s no room for either reading, given that
- Hellwig shows no interest on Rust, so references to the mascot are out-of-place
- A project is not a human being.
The immediate reading is as an analogy; cancer is known for spreading itself through tendrils, taking huge amounts of resources. If that reading is correct, Hellwig is criticising the project for not being well contained, and invading spaces that Hellwig believes that it shouldn’t.
Another possible reading is “cancer” as “shit”, “crap”, or “rubbish”; a simple negative word.
were it a slur, it would violate the prohibition on “insulting/derogatory comments, and personal or political attacks.”
And were my cat a chicken, she would lay eggs. However my cat is not a chicken and “cancer” is not a slur.
In this thread, much the same as in any discussion of the topic, we learn that Rust is vital to the survival of the Linux kernel and we’re surely doomed without it, and that the absence of languages other than C in the Linux kernel is the only thing preventing the demons of chaos from arising to tear our souls to shreds and we must remain pure.
That’s pretty much the impression I’ve been getting from following the whole thing very loosely.
looks like a lot of people want to die on the C programming hill. Cannot blame them, they have no will or ability to keep learning in an industry that *checks notes* …asks you to keep learning!
C is much simpler from a language perspective. It doesn’t have safety rails but it also has a lower learning curve assuming you understand computer hardware.
There are some warts of C that I feel Rust addresses very well. Mainly extensible type system that is not bad like C++. Secondly cargo. Building and packaging just feels wrong in C.
Only one place where C is still better than Rust: Rust does not have a well defined standard ABI. Hence every project compiles everything from source and link statically. Whereas with C we have a standard ABI that can allow for dynamic linking.
Does the Linux Kernel use simple C though?
I think and assume they use enforced guidelines, custom types and tooling to make it workable. By that point C is no longer simple. You extended the language to make it safe, and ended up with the same complexity.
C is simpler in the way that a motorbike is simpler than a car. Simplicity isn’t the only criterion or we would write everything in assembly which is really simple.
Assembly wouldn’t be viable because it requires rewriting for every architecture, C is the closest to assembly there is while still working on all architectures.
Honestly both takes a bad. On the one hand you should be open to new idea but on the other it is wise to stick with old and tested.
Rust is still a lot newer and less well tested. It isn’t going to replace C any time soon but it is cool that we have some Rust code in the kernel.
it is wise to stick with old and tested.
You mean old and known to cause endless security vulnerabilities.
I’m very skeptical of sticking to “old and tested” without reasoning.
If you’re talking about the implementation, if they’re making changes it’s no longer “well tested”. If it’s undocumented, it’s not approachable. If you’re talking about toolchain, if the old is unapproachable because of inherent toolchain barriers, and custom toolchain dialects, I think it’s good to question.
There may also be something to say about them struggling to get new contributors and maintainers (from what I heard/read).
His point could be valid, if C was working fine and Rust didn’t fix it. But C isn’t working fine and Rust is the first actual solution we’ve ever had.
He’s just an old man saying we can’t have cars on the road because they’ll scare the horses.
There are trade offs both ways. I think the right answer is to take it one step at a time. Write some kernel stuff in Rust and then see what happens in a few years time.
Write some kernel stuff in Rust and then see what happens in a few years time.
I think that’s what people are trying to do by writing drivers. To me, they seem like a perfect candidate for trying out Rust, they’re less tightly integrated from other parts of the code and preventing faults which can cause instability / security issues seems like a high priority. However, the code needs to integrate somewhere so bindings have to be written and it seems that is being blocked.
I’m personally on board with the comment left by @[email protected]. I think marcan is unnecessarily escalating this situation and I’d hardly describe Christoph’s behavior as sabotage. He does appear to have a real technical concern regarding maintainability and I think discussing that concern is more productive than dismissing it and calling him a saboteur.
Do you take this sentence seriously, or not?
I will do everything I can do to stop this.
As far as I can tell, “this” here refers to literally any Rust code that isn’t constrained within a specific driver. That does indeed seem like a full-on attempt to stop the R4L project entirely.
He does appear to have a real technical concern regarding maintainability.
“Appear” is doing some heavy lifting there. Opponents of the R4L project always couch their objections in technical concerns. For what it’s worth, I can’t actually find any concerns of merit or substance in that particular thread, although navigating mailing list threads is honestly pretty error-prone, so I may have missed it.
I do take it seriously and I think he’s overreacting a little but he does make a reasonable point. Bringing 2 languages into the kernel does create a divide that can come with a maintenance burden. The burden is probably worth the benefits but it’s still an additional burden and that is a valid concern IMO that should be properly addressed and argued with pros/cons rather than name calling and dismissal. Maybe he is acting in bad faith, but I feel like that should only be the conclusion drawn AFTER a reasonable attempt to talk things over has been made.
Additionally assuming someone is acting in bad faith when they’re not can make them jaded with the rust community and push them to actually acting with bad faith even if they weren’t before.
Regardless of the situation and whether he’s acting in bad faith or not I feel like marcan’s comments add nothing productive to the situation and that was my real point with the comment.
Bringing 2 languages into the kernel does create a divide that can come with a maintenance burden
There are already 2 languages in the kernel: C and Assembly(for example).
should be properly addressed and argued with pros/cons
That already happened and Linus decided to accept Rust code into the kernel.
Some people are very evangelical about Rust. They take any real concern as a personal attack.
I sense there’s going to be a lot of reasoning about maintainability and “greater good”.
Just kidding. It’s all biases and hate.
Build a second kernel.
Good grief. People like this Chris dude hold progress back. I’ll keep banging the drum (to be heard by not a single kernel dev, but anyway): the linux kernel need 90% of the Linux Foundation’s funding, not a mere 2%. There should be so many people wanting to be a maintainer that people who openly declare that they want to get in the way like this are easier to remove.
Are you a kernel dev? The people behind the kernel are the ones who are experience. They may be old and grumpy but they also are the ones who make sure that everything is well tested and carefully managed.
I’ve hacked kernel and I’ve listened to you; I don’t really think that your comments address the actual needs of the kernel. Also, both Christoph and Hector are kernel maintainers already; anybody who wants their responsibilities is welcome to match their level of contribution.
Is no one saying something because Christoph H. is just overreaching?
Because marcan is overreacting as usual, and is a very questionable character overall.
Great programmers often have personality or social problems
