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.
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.
“Follow rules to a letter” kind of sabotage manual.
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”…
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”.
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.
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.
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.
I don’t know how “whether more rust code should be allowed” is even a question. What, do you think they’re going to just cut all the rust developers off or something? Linus has always been a move slow and don’t break things kinda guy. Why should allowing rust into the kernel suddenly change that now? What is there to even answer?
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.
The dma maintainer wants all the code he’s in charge of to be stuff he likes to work with. Whether you agree with that or not, that has absolutely nothing to do with Linus Torvalds allowing more rust code in the kernel.
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.
Can someone distill the good faith argument against rust? Is there one?
Only one compiler nailed to LLVM. And other reasons already mentioned.
Syntax ugly
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.
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?
It will take more effort than writing kernel from scratch. Which they are doing anyway.
(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.
Could someone explain the backpedalling if rust is more secure ?
it’s a different technology and paradigm that the old guard would have to take considerable time to learn to be as productive as they are in C. it requires a different way of thinking about systems.
basically the rust-in-kernel-gang includes none of the “main” kernel team because they are busy building the kernel. this is an experiment to see if a second programming language can be successfully integrated into the kernel at all. if they try to force their way in, that’s going to cause problems for everyone.
Okey,
Same old story with any project with different generations. Looks like the old guys are in the wrong - wont be here forever and there by have to let in new ideas and ways.
Old people fear change
People who has been maintaining the kernel and weathered multiple fads are wary to see if new guards will “stick”, or just stay along for a year or five, disappear and leave the old guard with shit.
Thats also true…
Initially it sounded like that…
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.
It’s not devotion, people can fork the Linux kernel if they want. He’s just the one in charge of the mainstream kernel
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.
Well, I certainly don’t want to minimize what Linus Torvalds has done. No one has done more for open source software than him, but if he hadn’t come along with his kernel when he did there were other options. BSD did eventually get out of the legal purgatory that Linux gave an alternative to, or heck, maybe if Linux hadn’t come along Gnu Hurd could have even been a real thing.
I’m happy with Linus being in charge of the biggest open source project in the world. I agree with him more often than not. He’s not the only reason open source operating systems exist though.
Also a reply so you can understand a bit how things typically work in FOSS projects.
There’s a democracy in healthy ones, but ultimately, there has to be someone at the top that has the final say. The project maintainer/main contributor. Someone who gets to be the tie breaker, or absolutely final authority on what does or doesn’t make it into a patch/version/etc.
This is extremely common, and generally healthy, in these kinds of ecosystems.
Yes, that’s just the way it is in systems that involve humans. But when that final authority refuses to make a necessary decision, what do you do?
Is it healthy, or is it just the way it is? What makes it healthy?
Its not antithetical to the Foss philosophy. Thus happens because Linus is a trusted figure, something he’s absolutely earned. He didn’t just buy control of some product, or get promoted to this position by a company. Many great open source projects have a BDFL. If people lose their trust in the projects BDFL, they fork the project.
Also, the kernel is really just one part of Linux. Distros include a whole bunch of software they choose to deliver a full OS (hence the Gnu+Linux people). Linus doesn’t have control over the OS as a whole, just the kernel.
Edit: Just finished reading the chain, what do you mean the dude did a 180? He expressed frustration that Linux only criticized him, further criticized the issues with the kernel development process, and said he was giving up being part of the kernel.
I don’t know if it’s complete devotion, but Linus has a reputation he’s earned the difficult/hard way.
If he says something, people should take it seriously and consider his words. That’s not to say he’s right all the time, but you’d better have a damn good reason for disagreeing with him.
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.
It’s just respect
It’s not unfounded and I don’t know of a time when Linus wasn’t right in the end. But I wouldn’t say it’s blind devotion he would be turned on in a second he betrayed his principles. Also FOSS is not about lack of ownership its about sharing code for the greater good. Every owner of a project knows that a project can be forked in an instant.
I am so glad Linus just came out and said it. I was pretty upset at Hector too in the other thread the other day, and I especially didn’t appreciate a call to remove a major developer from the kernel because Hector wasn’t getting his way. Very militant action on Hector’s part where it just wasn’t necessary.
Hector, if you’re reading this, communication skills are just as if not more important than your Rust development skills, and frankly your communication skills lack.
You seem to be in the loops of the linux kernel?
If so, ive known hector from way before when we was part of f0f, or TT as they were known before, doing wii homebrew work.
What you describe is what my experience was with him 14 years ago too. The guy is smart, he has a very good skill set and knowledge, but his communication skills were lacking back then too.
Granted, both he and myself were still teenagers and students and we were wild, but i had always assumed he grew up a bit since then…What you said is spot on, and i hope he does read both of these. And if he does :
Marcan, you might not know who i am anymore, but ffs man. Dont screw up your love for all of these by keep kicking the hornets nests. You did it with devkitpro, emudevs when the nier news dropped and with rossman too. Stop it, its for your own good.and with rossman too.
I decided to read replies: wierd, they suggest accusation is overblown.
I decided to read context: WTF is this?! Unholy shit, dear Faust, what did I read? What a deflection!
I thought I was terminally online with mental disorders, but this makes me look most grass-touching and sanest person.
I can understand their frustration, having multiple other rust for Linux project maintainers quit over nontechnical rust aversion.
And Linus continues to (democratically?) avoid the subject with this response.
As a rust for Linux volunteer you have to be incredibly demoralized reading this mess almost every other month.
@semperverus Just from the small interactions I had with Hector on mastodon I can see he gets very unreasonable about small things and does not accept the possibility that he may be wrong, despite evidence. So leaving linux and mastodon because of rust is totally on brand for him.
So now we’ve lost a very good developer, and the question of rust in the kernel remains unresolved. This is the worst possible outcome.
Part of being a good developer is the “working well with other human beings” part. Linus himself took a hiatus to improve himself in this area.
Another part of being a good developer is to work within and adapting to the frameworks of an existing project, especially if you are joining at a later point. In this context, it would be the R4L folks joining the project known as “the Linux kernel.”
Hector failed on both counts. He has programming skills, but that’s not all that’s required.
Sure, and part of being a good manager is to, you know, manage. It shouldn’t have gotten to the point that marcan is going outside the list to try to get something done. Linus (or someone else with authority, I’m not familiar with who else is managing it) should have stepped in much earlier to head off the drama. It was a very simple question.
Rust in the kernel is already established and part of the mainline kernel. It’s extremely pretty and wholly inappropriate to reject code just because it’s written in rust.
If you had read Christoph’s reasoning, it wasn’t “just because it’s written in Rust.” He actually gave some decent technical reasoning for it that went beyond his original personal outburst (which I hold him to the same standard as Hector for, but he did shore up later and fixed his communication).
How do you figure?
The only two “technical” arguments I could see were firstly that code should
[remain] greppable and maintainable
which unless I’m missing something boils down to “I don’t speak Rust”, and secondly that
The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this
which unless I’m missing something boils down to “I don’t speak Rust”, because ain’t nobody trying to add any other languages to the Linux code base.
Surely this can’t be the “decent technical reasoning” you are referring to? I have to admit I don’t follow kernel development that closely, but I was under the impression that integrating Rust into the code base was a long discussed initiative having the “official” blessing of the higher ups among the maintainers by now, so it seems odd to see it opposed in such harsh terms by a subsystem maintainer here:
I absolutely support using Rust in new codebase, but I do not at all in Linux.
You and i read different things. I hated how he worded them, but his arguments at greppable and understandable are valid arguments that go beyond rust and if he can read it or not or refuses to.
Mixing languages in a part of a project brings complexity and is often a huge ass nono because it makes things unreadable and hard to manage on a large scale.
He also argues that a c interface exists to connect 2 parts of a system. The person that changes the interface should not have to alter the users of that interface, if they do then you get intertwined dependencies, which is a huge ass red flag for developers that something has gone terrible wrong and the project is not going to scale or will be easy to change.
So if he changes the interface, the rust team will need to fix it, specially since they are the minority.
That also doesnt mean he can change it in whatever way without worry, it is an interface change, that needs discussions and approvals ahead of time ofc.
Most full of shit comment in the thread
I don’t think this is the worst outcome. It would have been worse if he was the face of Rust in Linux and I’d died out over ten years instead of one.
That being said, hopefully it can get a fresh start.
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 conspicuous did not answer that question either.
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
