Behold, a Linux maintainer openly admitting to attempting to sabotage the entire Rust for Linux project:
https://lwn.net/ml/all/20250131075751.GA16720@lst.de/
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/20250128092334.GA28548@lst.de/
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/2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st/T/#m1944b6d485070970e359bbc7baa71b04c86a30af
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.
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?
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’m personally on board with the comment left by @equinox@chaos.social. 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.
There are already 2 languages in the kernel: C and Assembly
Assembly and C share a very very close relationship. C is really just high level ASM and ASM is used as little as realistically possible in the kernel so the situation is different.
That already happened and Linus decided to accept Rust code into the kernel.
Doesn’t mean you should neglect the opinion of every other maintainer. I’m not saying rust shouldn’t be included here or that Linus shouldn’t have the right to override his opinion. I am saying calling names as opposed to discussing his concerns is not productive. FOSS is a collaborative space and that collaboration is important even if redundant at times.
Both of your technical claims are wrong. C isn’t high-level assembly; on e.g. x86, it has no way to express SIMD, control I- and D-caches, or encode certain efficient instructions for which there is no corresponding idiom like Hamming weight (popcount). Also, the kernel does not have any sort of policy mandating a minimum of assembly, and there are definitely many spots where writing a compilation unit purely in assembly is done instead of using inline assembly to make the unit shorter and more readable.
C is basically high level assembly. It’s hardware agnostic high level assembly. I have written both, this is personal experience and also I believe even Linus has said EXACTLY that statement. It is an opinion ofc and you’re welcome to disagree but it isn’t just me.
I never said it was a policy but it’s definitely true. Inline assembly IS still assembly. I’m saying if the code can be written in C it more than likely will be over assembly unless there is a very good reason to write it in ASM. The kernel is 97.97% C and just over 1% ASM. If that doesn’t prove what I’m getting at Idk what else will. It’s a totally different circumstance than replacing large swaths of C with rust or introducing large amounts of rust in favor of C.
Whose arguments are you apologizing for? Read the thread backwards. Your claims about C and kernel policy were wrong, therefore @pressanykeynow@lemmy.world’s point about multiple languages was right, therefore your main defense of Hellwig acting in good faith is unevidenced. So, are you still so ready to insist that Hellwig is arguing in good faith? Would you say that this thread has adequately discussed the technical details and is ready to return to the overarching political point?
I would recommend looking at English WP’s style guide on weasel words. Rather than matching evidence and countering claims, you’ve set up a nest of strongly-held opinions with words like “basically”, “personal experience”, “I believe”, “an opinion of course”, “it isn’t just me”, and refused to actually directly engage with the evidence scrutinized. Given that it takes maybe five minutes to find even just one piece of assembly that has no justification for not being written in C, I think that it’s fair to characterize your position as inconsistent with actual kernel-hacking practices at best.
I wrote a longer reply with links, but somehow it didn’t actually post; so this will be shorter and unsourced. Sorry about that.
There already was a discussion, over the course of several years, about whether to add Rust to the kernel. Linus merged
rust/kernelinto the mainline in 2022, and it was released in Linux 6.1. The patch that Hellwig opposed did not introduce Rust, it just added more Rust.Hellwig also made it pretty clear that he wasn’t open to discussion. If you read the thread, there were numerous attempts to “talk things over.”
You may be right that Marcan’s posts on Mastodon added nothing productive, though I honestly think there’s some value in sharing behavior like Hellwig’s with the broader programming community. But his posts in the actual mailing list seem pretty sensible, albeit provocatively worded.
Also, in case you didn’t know, similar behavior (to Hellwig’s) led the primary Rust for Linux maintainer, Wedson Almeida Filho, to step down back in August. Marcan is correct that the anti-R4L maintainers are successfully demoralizing the R4L people.
Some people are very evangelical about Rust. They take any real concern as a personal attack.
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.
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.
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.
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.
Everything else is distractions orchestrated by a subset of saboteur maintainers who are trying to demoralize you until you give up, because they know they’re going to be on the losing side of history sooner or later.
This isn’t true though, he stated his motivation clearly.
Removed by mod
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.
The R4L devs are literally saying (and have been for years at this point) that the c devs do not need to touch a single line of rust nor maintain any part of the integrations. So it’s quite backwards from what you’re saying. Specific c devs are complaining for no reason.
I believe writing the pure kernel is doable in time, but Linux has a ton of drivers, also implemented in C. I also believe it’s not unreasonable to assume that those are the source of most of the issues that Rust would solve. I’m nowhere close to actual kernel development myself though either.
Migrating such a huge, complex code base over however as much time to a different language seems completely unrealistic to me though. What you’re saying is right. It makes more sense to keep a pure C Linux kernel and work on a replacement in parallel. No matter how great a new language is, you can’t expect an entire community of seasoned contributors to adopt it. It’s unreasonable
The push to force rust into linux feels weirdly inauthentic. I’m guessing the build chain has been appropriately compromised to add backdoors at build time.
