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.
this post was submitted on 03 Feb 2025
108 points (84.2% liked)
Linux
6090 readers
442 users here now
A community for everything relating to the GNU/Linux operating system
Also check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
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 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.
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.
load more comments
(6 replies)
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?
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”?
Torvalds? Apparently, yes.
load more comments
(11 replies)
As a programmer who integrates many languages together in the same product this is a pretty clear line in the sand. Where the languages interface, it's up to the new language to adopt the interfaces offered by the older language. Rust guys said they will do this, C guys said why don't you assume this responsibility (they already are). This is either a miscommunication or deliberate scape goat reasoning and deflection. There is no good reason why two languages can't work together with interfaces. I think the C guys are old, grumpy and fearful.
Disclaimer: I don't even like Rust as a language. Just calling it how I see it.
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.
load more comments
(5 replies)
load more comments
(1 replies)
load more comments
(1 replies)
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.
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.
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.
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.
load more comments
(1 replies)
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.
That's pretty much the impression I've been getting from following the whole thing very loosely.
load more comments
(4 replies)
Is no one saying something because Christoph H. is just overreaching?
load more comments
(4 replies)
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.
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.
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.
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.
load more comments
(1 replies)
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.
view more: next ›