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
105 points (83.9% liked)
Linux
6307 readers
243 users here now
A community for everything relating to the GNU/Linux operating system
Also check out:
Original icon base courtesy of [email protected] 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.
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.
I am not a programmer. … I’m a random with a chimp avatar. … It’s just that [Hellwig] prioritises consistency (for the sake of maintainability)…
Pick a side and stick to it. You seem very keen to endorse Hellwig's arguments despite not understanding them, and also to emit words on the topic despite not having a qualified opinion. It sounds like you want me to not take you seriously (so that I won't reply to you) and also take you seriously (so that you are counted as part of the programming public.)
I'm docking you again, this time for listening comprehension. Quoting Gaynor:
The common thread here is that for each of [six listed vulnerabilities exploited by nation-states against vulnerable minorities], the vulnerability that was executed … was only possible because of the victim's software being written in a memory-unsafe language. Put another way, if the relevant portions of these projects were written in a safe language, these vulnerabilities wouldn't have been possible.
That was early in the talk, around 6:30. Later, around 19:40, he says:
The Rust-for-Linux project is working to make it possible for people to write Linux kernel modules in Rust.
So, if you had watched Gaynor's presentation, you would understand that Rust-for-Linux is a significant and prominent part of a wider push by security professionals to improve the overall safety of common devices, like Android phones, that are in the pockets of millions of people already. And then you wouldn't be talking about respectability politics while apologizing for reactionaries who oppose that safety.
load more comments
(2 replies)
load more comments
(1 replies)
load more comments
(5 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 @[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.
load more comments
(5 replies)
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/kernel into 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.
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.
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.
load more comments
(1 replies)
load more comments
(5 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.
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.
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)
view more: next ›