https://lore.kernel.org/lkml/20250108122825.136021-1-abdiel.janulgue@gmail.com/
Here’s the source thread.
Tldr: someone wants to put rust in the dma part of the kernel (the part that accesses memory directly)(it’s a memory allocator abstraction layer written in rust which rust code can use directly instead of dealing with the c allocator abstraction layer), is told that rust should use the extant methods to talk to the c dma interface, replies that doing so would make rust programs that talk to dma require some more code, gets told “that’s fine. We can’t do a split codebase”. The two parties work towards some resolution, then hector martin comes in and acts like jerk and gets told to fuck off by Linus.
Martin is no lennart poettering but I don’t try to see things from his perspective anymore.
It’s worth noting that Linus’ “approval” of rust in the kernel isn’t generally seen as a blanket endorsement, but a willingness to see how it might go and rust people have been generally trying to jam their code everywhere using methods that rival the cia simple field sabotage manual.
I don’t think it’s on purpose (except for maybe Martin) but a byproduct of the kernel maintainers moving slowly but surely and the rust developers moving much faster and some seeing the solution to that slow movement as jamming their foot in the door and wedging it open.
To be fair, I’m not sure how “I will do everything in my power to oppose this” is the anti-Rust side “work[ing] towards some resolution”…
That’s tame for the kernel mailing list lol.
The context is that hellwig doesn’t want another maintainer or deal with a split codebase in the dma subsystem which I honestly agree with.
If I were a maintainer in that position I’d be barring the doors too. It’s not a driver for some esoteric realtek wireless card or something.
Even if I didn’t agree with that position it’s normal to only post on the kernel mailing list about shit you actually care deeply about because it’s public and aside from all your fellow devs taking the time to read what you wrote, psychotic nerds like myself watch it and will try to read the tea leaves too!
Sure, I don’t think it’s like toxic or anything, but I also understand why Martin viewed the situation as an impasse requiring a decision from on high. Also, from my limited understanding it sounds like the new code was in a sequestered rust-only section of the dma subsystem, so I’m not clear on exactly what new burdens were being placed on the C dma maintainers.
My understanding is that the rust code in question implemented parts of the c dma interface so that rust programs could use that instead of the c dma interface.
I’m out in the world, not sitting in front of a computer with the source open so that guess will have to do for now.
The most immediate problem with having two different dma interfaces is that now you have two maintainers and an extra step at best when making any changes.
https://lore.kernel.org/lkml/293df3d54bad446e8fd527f204c6dc301354e340.camel@mailbox.org/
General idea seems to be “keep your glue outside of core subsystems”, not “do not create cross-language glue, I will do everything in my power to oppose this”.
deleted by creator
If you read the article, the main issue is not the fact that it’s Rust itself, but that it’s a second language entering the codebase. There’s definitely some validity to the argument.
My personal view is that any C developer who doesn’t want to learn Rust is going to kick themselves once they do.
They specifically name and shame rust as the shiny new language of the day. It does make it seem like a personal grudge against rust specifically.
the main issue is
Sure. But I’ve seen quite a bit of push back against rust from these sorts even outside the kernel.
trying to jam their code everywhere using methods that rival the cia simple field sabotage manual.
I am aware of the manual, but I fail to see how adding to a codebase is “sabotage” if it’s all generally seen as fine by the project lead - it’s far from a hostile takeover.
Would a CIA saboteur even want memory safety as a rule? Just speculating, but I’d say that’s unlikely.
Edit: I changed the order of the sentences, as it was not intentionally ordered, and slightly clarified my second thought.
I don’t think the ends are those of the cia, and I didn’t say that the means were either, only that they were similar to those in a famous mid century guide for those trying to halt or hijack organizations.
I don’t think the rust devs are a cia opp, before you ask. I think some rust devs and even proponents of rust who only cheer from the sidelines are sometimes behaving in ways that raise red flags. I think it’s natural and laudable that the existing devs and maintainers are alarmed by that same behavior. It’s their job.
I also think Linus position on rust has been stretched to the point of breaking and I personally find it hard to take positions seriously that distill the complex process of integrating new languages into a very old very large codebase with many full time developers into “Linus said I could”.
Again, I am aware of the manual. I was recently exposed to it, as well, so it’s very fresh in my mind. I understand why you mentioned it and understand what you are saying, but I disagree, I don’t see the parallels.
I think Linus just wants the drama to stop and the progress to flow, but I’ll let him speak for his emotions towards the R4L project and avoid speculating about him.
I’m just openly speculating that there are vulnerabilities in the code, and that the R4L project will uncover those as a natural product of its evolution. I don’t think a CIA sabotage manual is apt to describe the R4L project, largely because I see it as progress. From my perspective, maintaining old C code is not something they are sabotaging.
As opposed to the R4L members, there are those who are openly admitting to sabotaging the progress of the R4L project. If you’ve seen the past public clashes between the R4L project and the Linux kernel community, you’d also be able to garner that from those interactions as well.
It’s surprising to see that statement get brought up in the news considering it’s immediately followed by a parenthetical specifically enumerating a multi language code base as the subject not rust specifically.
Iirc it’s even preceded by something to the effect of “I like rust, it’s good and there’s nothing wrong with projects that use it”.
The news coverage of kernel mailing list stuff is always so needlessly breathless.
From my understanding, it’s not Hellwig’s job to maintain the Rust side of the code. They can find multi-language codebases a pain all they want and throw a gigantic tantrum focused towards the R4L project - it doesn’t affect the code that they are responsible for. I don’t see why the whole R4L project couldn’t just be removed if R4L is not maintained by those who develop and support it.
but I will do everything I can do to stop this.
Is an open admission of Hellwig to sabotaging the R4L project.
Seeing the R4L folks as saboteurs or anything close is not in evidence. This isn’t the '90s, we have the means to be a lot more productive in regards to coding and managing codebases, and historical maintenance problems are irrelevant. If the R4L team is truly sabotaging the codebase by adding too much complexity or overhead, there are levers that can be pulled to change their direction without blindly rejecting or hindering their efforts.
Again, so much of the discussion around kernel mailing list exchanges excludes the context that what hellwig is talking about is not rust in the kernel at all or even r4l but a split code base.
I dealt with a c/c++ codebase once and it was beyond my meager abilities to handle both those ostensibly similar languages at the same time and I had people who were very knowledgeable in c involved with the project.
So when someone says “I think a split codebase is cancer to the Linux kernel” or “I will oppose this (split codebase) with all my energy” I’m like “yeah, that makes sense.”
I also need to clarify that I don’t think anyone is sabotaging anyone else and my intent in bringing up the simple field sabotage manual was to point out that the behaviors don’t necessarily indicate sabotage but fall into a broad category of behavior that isn’t gonna solve problems or get anywhere which is why it’s included in the manual.
I wasn’t aware it was circulating in social media recently and about fifteen years ago when I got exposed to it the main lessons to draw were not that people doing those things were active saboteurs but that those behaviors can lead to waste of energy and resources and they’re the first thing to avoid interacting with.
My exposure to and understanding of the manual was “here are some things to avoid in your own life” not “here’s how to throw a wrench into their plans!”
I don’t think the R4L project is for naught or is impeding progress. I see their good faith and their efforts. A split codebase can just be chopped off at the base and business can move on as usual at any point.
If Linux kernel maintainers are against potential improvements being found to the existing C code as a result of parallel development, then perhaps they should require the Rust developers to suggest what the added/changed code could look like in C (if possible) and their reasons for changing the implementation in Rust before they can push their implementation (forcing R4L to shoulder the brunt of the work) - or force R4L to stick to close-approximations and working within the existing system to properly change existing functionality through established processes.
I apologize that I misrepresented his arguments, I of course meant to say that his problem was a split codebase and I understood as much, I just misspoke. Other comments have enlightened me to better understand his arguments and concerns since I posted, as well.
You: […] have been generally trying to jam their code everywhere
I suppose your earlier statement was just stuck in my head, and I was wondering to what extent they have “infected” the codebase with Rust.
And I learned about the manual when a creator I was linked was talking about how there are parallels between the manual and the decline/failure of the U.S. education system, but I similarly disagreed with them that the issues of the U.S. education system are due to internal or external sabotage (through any methods described in the manual, whether intentional sabotage or not) or anything close to it. This was before Trump.
“Follow rules to a letter” kind of sabotage manual.
Except you’re wrong about them wanting to put Rust code in the DMA subtree. As per the article linked below by M1ch431:
In a message to the Linux kernel mailing list, Hellwig wrote: “No Rust code in kernel/dma, please.” For what it’s worth, the patch added code to the rust/kernel portion of the Linux source tree, not kernel/dma, as far as we can tell.
All they were doing is adding an abstraction layer, within the already existing Rust code, so that rust drivers could communicate with the C DMA code in a uniform and predictable manner. It would have put far more work on maintainers, both C and Rust alike, to have each and every driver implement its own abstraction to the DMA API. Issues would have been/will be filed against the kernel/dma subtree in error due to issues with these myriad abstraction layers.
It’s a duplication of functionality in kernel/dma.
That’s why the submitter didn’t say “I didn’t submit to kernel/dma, checkmate libs!”.
The intent is to duplicate functionality in kernel/dma then get it included directly or linked to.
That’s what the r4l project is trying to do explicitly!
Before you say that kernel/dma didn’t have functional easy to use rust bindings, so the commit couldn’t have duplicated functionality: someone on kernel/dma said they didn’t want that and suggested using the c bindings instead which is what every other language has to do. Which means there was already a solution that was functional.
It’s like if there’s a community bicycle and you bring your drill and tap set so you can mount your bottle caddy and the community says “please don’t make a hole we have to tig in. Just use a pipe strap.” The right answer isn’t to start building a whole new down tube you can tap for an m5 for your bottle caddy, it’s to just use a pipe strap for your bottle caddy.
I didn’t read the linked article (or any linked article about this) because I’ve been reading the mailing list. Reporting on the kernel and people’s behavior on the list is tiring and often includes a bunch of baseless speculation.
FTA: "However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach.
"Because if we have issues in the kernel development model, then social media sure as hell isn’t the solution. The same way it sure as hell wasn’t the solution to politics.
“Technical patches and discussions matter. Social media brigading - no thank you.” -Linus
Yeah, I have to issue an unqualified agreement here. Linus isn’t saying no to Rust, he’s smackin’ that ass for bringing drama out into social media instead of working through it in normal technical discussion channels.
It sounds like he tried that, and nobody with authority responded until he went outside the list. Even now, Linus hasn’t actually answered the question of whether more rust code should be allowed.
No offense, but reading through the comments it’s apparent you’re not very familiar with systems programming nor linux development. This is a common problem with vocal ‘rustaceans’, rust is their hammer regardless of the domain.
Although considering rust is prudent, there are still a ton of advantages to using C for systems programming. It is not a binary choice, there are pros and cons, and every project should choose what aligns with their priorities.
No one has ever stated that linux will be in the kernel. It was ‘go ahead and give it a shot’, which includes convincing maintainers to accept your patches. Linus has delegated trust to subsystems maintainers and an established process.
Hellwig could have been more tactful, but like it or not, arguments against a cross-language codebase have merit. Framing it as a ‘clear confession of sabotage of the r4l project’, attempting to weaponize the CoC, and trying to drum up an army via social media was all out of line.
Success was never a given, if they want r4l to succeed then they have to get patches approved and crying wolf ain’t gonna cut it.
Isn’t on of the issues on why they wanted rust is a lack of new blood in the kernel development?
deleted by creator
Well, the rust devs are trying to add more rust code, and the dma maintainer rejected it because it was was written in rust. Thus, the question.
deleted by creator
That’s the thing though, he’s not in charge of this code.
deleted by creator
He’s not in charge of the rust code they want to merge. They asked him about it because their code talks with the dma system.
Sure, I saw that, too. This is Linus saying he won’t play that.
So he won’t answer on-list. He won’t respond to off-list. I don’t blame marcan for getting frustrated.
Yeah, I don’t blame him for being frustrated. I definitely empathize with him here. I don’t know about the culture around committing to the kernal, but maybe it would be better to fork and make the case with action?
Forking the Linux kernel is unlikely to go anywhere.
There is Redox, a Unix-like whole OS implemented in Rust, though I don’t know if being able to run unmodified Linux binaries is one of their goals. It looks like they’re expecting most software to be ported.
The quote he replied to:
If shaming on social media does not work, then tell me what does, because I’m out of ideas.
Yeah, lol
Yeah, Linus conspicuously did not answer that question either.
I’m relatively new to Linux and the FOSS scene, but I’m not sure how I feel about the unquestioning devotion to a single person. It seems antithetical to the entire philosophy.
Even if he was maybe right this time…
The dude did a complete 180 as soon as they heard from Linus, like daddy made his decision, and it’s final, or some shit…
Edit: To be clear, I understand why developers respect and listen to Linus… I just think there are fundamental issues with this kind of top-down management of such a colossal project, and the desire to defer to one person seems antithetical to the FOSS philosophy.
I don’t think it’s blind devotion - most of us would acknowledge the guy can be a bit of a dick sometimes.
But we’re also grateful. Without his silly idea in the 90s, linux wouldn’t exist. Computing today would be massively different - big, commercial, massively expensive unixes like Sco and Solaris dominating the industry. My main hobby for 20 years would be very different. My career for six years wouldn’t exist.
That Linus has stayed an actively contributing member whilst not selling out in any way at all for 34 years is… wow. Could you do it? I’m certain i couldn’t. I have neither the ethical strength nor moral compass to do it. And I’m certain if he dropped out, some of the massive egos that satellite around Linux, or the monetizing businesses would seek to take over and twist it to their needs.
And, y’know, on the matter of technical detail like this. He’s nearly always right. Seriously, look it up. He’s not polite, he’s not diplomatic, but he’s nearly always right. And when he’s not, he’ll admit it. Again, not your normal human.
So yeah, that’s why we respect him and, when he talks, we listen. Even if it’s not something we’re involved with, it’s usually an interesting ride.
deleted by creator
He is why they’re popular. Who knows if any of those would have gained traction. I mean Hurd is still non existence and for whatever reason BSD is a niche of a niche.
deleted by creator
If Linus genuinely went off the rails, the kernel would just get forked. Even right now, if the way the mainline project is run doesn’t work for someone or what they are doing, that can and does happen.
Linus has power because the people who contribute to the project allow it, and they allow it because over the years he has consistently endeavoured to make decisions based on what is in the best interest of the project. People want him in charge, because he has done, and keeps doing, a really good job.
He hasn’t always been nice to deal with, and he can get spicy when he puts his foot down, but whem he does, its not on a whim. And if he’s wrong, and you can articulate why and how, in good faith, he won’t ignore the logic of what you are saying out of some childish sense of pride.
Unless a major corporate sponsor of Linux forks it s fork is going no where. The amount of company work that goes into the kernel is massive.
It’s just respect
The BDFL model, as it’s called, is what allows large projects to continue to have focused vision rather than devolving into design-by-committee. The kernel is actually already well beyond pure BDFL, but my point is having a single point of overall leadership can be a huge boon for the organization of large and complex projects. FOSS philosophy has literally nothing to do with management structure; it’s entirely about the rights of the end user.
BDFL is not without its own risks. WordPress is a good counterexample these days. But, when someone originates a project and sticks around to steer it, it would be silly to reject their proven successful leadership for such a vague reason as you have presented.
When things do go sideways, people are free to fork the project. That is what FOSS is.
This whole thing reads not like a codebase versus, but a traditional engineering approach (don’t act like you can patch this once you release it - get it done so it’s stable the first time) versus the more modern “move fast and break things” approach.
Rust people are so annoying.
counterpoint: stonewalling c programmers are so annoying.
Honestly I kinda wish the Rust devs would rather go and support a project like Redox OS and then maybe we can have less drama about all this.
linux is amazing. i dunno what rust is, but ive been using linux a long time. i appreciate the modern comfort. but whatever happens happens. itll still be good.
If code doesn’t change quickly enough, it rusts. Linus makes sure that doesn’t happen
My gut tells me that any benefits of adding Rust is massively negated by the addition of a second language.
If one wants to write Rust, there is always Redox and probably a bunch of other kernels.
I like Rust, but it’s for sure an over hyped language. In a year or two, people will push for Zig, Mojo or some new pure and polished functional low level language. Maybe a Scheme or a Lisp? That seems to be what the cool kids use nowadays.
Or maybe we’ll just replace the kernel with an AI that generates machine code according with what should be your intention.
deleted by creator
I’m not saying that Rust will go away.
deleted by creator
My point is simply that it’s probably not worth it to add another language. Doesn’t have anything to do with Rust really.
Though I do think that the language is a bit over hyped. It’s obvious companies and projects used to say they’re using Rust, not just because they want to attract young developers or like the language, but because it’s a way to get VC. Like AI and blockchain.
I do like Rust. But mostly because it encourages functional style programming. And the tooling is of course awesome. Especially compared to C and C++. However, I do believe that static pure functional languages are superior to Rust.
he looks like some kind of dino, i cant figure out which one
This is just a dick measuring contest.
Can someone distill the good faith argument against rust? Is there one?
it’s more niche than C, has less competency available, works very differently to C, and requires a whole new toolchain to be added to the already massive kernel compilation process. for it to be plain sailing adding it to the kernel some of the worlds’ foremost domain experts on operating systems would have to re-learn basically everything.
also since rust is just coming up on 15 years of existence without a 1.0 release, there’s no way to ensure that the code written today will be considered well-formed by the time 1.0 hits.??? Rust 1.0 was released 10 years ago and since then there have been no breaking changes.
so it was! cool!
i will admit i’m not very well versed in rust, the only time i’ve used it was in like 2016, in an embedded context where there were hard restrictions on what could be used. no crates, no macros, no traits, no threading, and a very limited number of functions. procedural style, basically. someone else chose the wrong language and i just had to work within the system.
if the language is stable, i’m assuming the instability issues come from external crates? or are they just made up?
I havent noticed any problems with instability, at least for web server development it is stable enough. But it may be different in other contexts like embedded. And its true that many libraries still have 0.x versions.
Only one compiler nailed to LLVM. And other reasons already mentioned.
Can someone distill the good faith argument against rust? Is there one?
The problem is that even if it’s objectively better, you can’t magically convert everything instantaneously, and it’s a lot more work maintaining rust and C versions of the same code until everything is re-implemented in rust.
If the rust devs are willing to take on that work, what’s the problem?
(n.b. I am neither a rust, nor C developer so I am writing outside my own direct experience)
One of the arguments brought up on the kernel.org thread was that if there were changes to the C side of the API, how would this avoid breaking all the rust bindings? The reply to this was that like with any big change in the Linux kernel that affects multiple systems with multiple different teams involved, that it would require a coordinated and collaborative approach — i.e. it’s not like the rust side of things would only start working on responding to a breaking change once that change has broken the rust bindings. This response (and many of the responses to it) seemed reasonable to me.
However, in order for that collaboration to work, there are going to have to be C developers speaking to rust developers, because the rust developers who need to repair the bindings will need to understand some of what’s being proposed, and thus they’ll need to understand some level of C, and vice versa. So in practice, it seems nigh on impossible for the long term, ongoing maintenance of this code to be entirely a task for the rust devs (but I think this is taking an abnormally flexible reading of “maintenance” — communicating with other people is just part and parcel of working on such a huge project, imo)
Some people have an ideological opposition to there being two different programming languages in the Linux kernel full stop. This is part of why the main thing that rust has been used for so far are drivers, which are fairly self enclosed. Christoph Hellwig even used the word “cancer” to describe a slow creep towards a codebase of two languages. I get the sense that in his view, this change that’s being proposed could be the beginning of the end if it leads to continued prevalence of rust in Linux.
I haven’t written enough production code to have much of an opinion, but my impression is that people who are concerned are valid (because I do have more than enough experience with messy, fragmented codebases), but that their opposition is too strong. A framework that comes to mind is how risk assessments (like are done for scientific research) outline risks that often cannot be fully eliminated but can be reduced and mitigated via discussing them in the context of a risk assessment. Using rust in Linux at all hasn’t been a decision taken lightly, and further use of it would need ongoing participation from multiple relevant parties, but that’s just the price of progress sometimes.
It will take more effort than writing kernel from scratch. Which they are doing anyway.
that article is horrible to read! every paragraph starts with quotation, but then never closes it😵
