this post was submitted on 13 Feb 2025
315 points (97.6% liked)
Linux
49964 readers
916 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
How can it happen if individual maintainers say they'll do everything in their power to keep Rust out of the kernel? There's fundamentally no way forward. The R4L devs already gave every commitment they could, but some maintainers fundamentally don't want it.
And before anyone brings it up: no, the maintainers weren't asked to touch Rust code or not break Rust code or anything else.
Fact is Rust isn’t ready for every part of the kernel. C/Rust interop is still a growing pain for Linux and troubleshooting issues at the boundary require a developer to be good at both. It’s an uphill battle, and instead of inciting flame wars they could have fostered cooperation around the parts of the kernel that were more prepared. While their work is appreciated and they are incredibly talented, the reality is that social pressures are going to dictate development. At the end of the day software is used by people. Their expectations are not law, but they do need addressed to preserve public opinion.
Again: what cooperation is possible when the maintainer says "I'll do everything in my power to keep Rust out of the kernel"? When they NACK a patch outside of their Subsystem?
Can a maintainer really NACK any patch they dislike? I mean I get that Hellwig said he won't merge it. Fine. What if for example Kroah-Hartman says "whatever, I like it" and merges it nonetheless in his tree?
I doubt Greg is pulling in Rust until it has been through the mainline. That said, Linus can merge anything he wants.
It was an example. I don't have a fucking clue how all the maintainers are named.
The main question was: why can a maintainer NACK something not in their responsibility? Isn't it simply necessary to find one maintainer who is fine with it and pulls it in?
Or even asked differently: shouldn't you need to find someone who ACKs it rather than caring about who NACKs it?
Yes, but asking him in this case was basically a courtesy, the code isn't going into anything he manages. He can reject it, but that's an opinion, not a decision. It can still be merged if the regular maintainer (or someone senior like Linus himself) approves.
Can you quote where that was said?
I've been following this debate for a bit and as far as I can tell it's not so much that they'll do what they can to keep rust out but more to make sure that the people who want to develop in rust are the ones who end up maintaining that part of the code and not the current maintainers.
Sure: https://lore.kernel.org/rust-for-linux/[email protected]/
Can't get more explicit than this.
Then rust isn't going to happen in every area of the kernel yet
Which means unnecessary duplication of code, because every driver has to track kernel Interfaces separately. Why? What's the advantage?
It will happen via it being better, and being shown to be better. And it will take time to unseat 30 years of C.
Not if they're being prevented from showing to be better by C devs who, literally, "will do everything [they] can do to stop this".
Nobody is trying to unseat 30 years of C.
Nobody prevents anyone from maintaining their own tree, thereby proving it works.
And yes, Rust is trying to replace C, in the kernel. Let's start off by being honest here, k?
If we are going to be honest, let’s not be misleading.
Nobody is looking to replace C in the kernel just to switch out the language. This is not a “rewrite it in Rust” initiative.
What the R4L folks want is to be able to write “new” code in Rust and for that code to call into the C parts of the kernel in an idiomatic way (idiomatic for Rust). So they need to create Rust interfaces (which they, the R4L side, are doing). This whole controversy is over such an example.
At this point, we are talking about platform specific drivers.
Now, new kernel code is written all the time. Sometimes newer designs replace older code that did something similar. So yes, in the future, that new code may be written in Rust and replace older code that was written in C. This will be a better design replacing an inferior one, not a language rewrite for its own sake.
Core kernel code is not getting written in Rust for a while though I do not think. For one thing, Rust does not have broad enough architecture support (platforms). Perhaps if a Rust compiler as part of GCC reaches maturity, we could start to see Rust in the core.
That is not what is being talked about right now though. So, it is not a reasonable objection to current activity.
If R4L authors want to use Rust so badly, then still:
Maintain your own tree! Let's see how simple and clean these interfaces are over the longer haul.
They will get mainlined if they are technically superior.
I doubt you care but others may want to know that you just hit the nail on the head. Just not the way you think.
All the Rust folks want is for “technically superior” solutions to be accepted on their merits. The exact problem is that some influential Linux folks have decided that “technically superior” is not the benchmark.
Take the exact case that has led to the current debate. The maintainer said explicitly that he will NEVER accept Rust. It was NOT a technical argument. It was a purely political one.
In the Ted Tso debacle. a high profile Rust contributor quite Linux with the explicit explanation that the best technical solutions were being rejected and that the C folks were only interested in political arguments instead of technical ones.
If it was true that “technically superior” solutions were being accepted, the R4L team would be busy building those instead of arguing.
It was merged into mainline, in 6.1, over a year ago.
https://docs.kernel.org/rust/index.html
Then this isn't being blocked?
I don't know if the code marcan was talking about is still going to be merged. It wasn't actually being blocked, but that doesn't mean it was approved either.
So, not blocked, merged in, already maintaining a tree, just one maintainer isn't sold yet on the implementation.
Im just not seeing a problem then? Aside from the person experiencing burnout, which I get. But burnout may not indicate a cultural problem, either. Especially if the person is coming off of a rough year, personally.
Yet the Linux project officially OK'd the R4L experiment, so why does this stuff still have to be kept out-of-tree?
No, Rust is not trying to replace C in the kernel.
Sure, why don't you give it a try?
Yes, it's been ok'd. That means it's ok to go in, once proven.
So, R4L peeps need to figure out how to convince maintainers that is works.
So, go do it?
How do you convince a maintainer that NACKs a PR outside his subsystem while explicitly saying:
Please explain how one can convince such an individual.
I already did: maintain your own tree, and prove it out, that it's better.
If the maintenance load is so light, it'll be easy work to do, to keep the tree in line with upstream.
If it's so obviously technically better, people will see it, and more people will push to mainline your tree.
It's work. And you need to convince others on technical merit. So, do the work.
Just like what folks did with OpenBSD, the grsecurity tree.
The maintainer literally says the issue is that there are two languages. There is no way to convince them, there's nothing anyone can do.
The maintainer didn't say "I worry about the maintainability, please prove that it works outside the tree" (this concern was already discussed when the R4L experiment was officially OK'd). They are explicitly saying they'll block Rust in the kernel, no matter what.
I don't know how to better explain this to you.
You’ve brought this up in several comments. given the situation, what do you think is the answer to replacing a huge c codebase with rust under the specific conditions of Linux development (open source, overwhelmingly maintained by 9-5 lifers employed by disparate organizations, in use everywhere for everything) when maintainers say they’ll oppose it?
Microsoft made the news a year or so ago announcing a rewrite of some libraries in rust, but conditions and limitations in Redmond are very different than those faced by the kernel team.
Nobody is trying to replace a huge C codebase.
The project lead OK'd the R4L experiment (which, again, is NOT about replacing C). Why should individual maintainers be able to completely block this outside their own subsystems?
Okay so if the point of the rust for Linux project isn’t to replace c code with rust then what is the point?
I understand the project maintains a coy line regarding that question but let’s be serious for a second and really consider why r4l is happening.
The purpose is to allow new modules to be written in Rust, not to replace C code. Why are you acting like you don't know this already?
So why can’t rust modules use the c bindings?
What im building towards is: if r4l isn’t about replacing c code then it doesn’t need to be in the kernel. If its about replacing c code (which it absolutely should be, that’s the whole point of memory safe languages like rust) then r4l people need to have a clear process and understanding of how they expect to accomplish that goal and be open about it.
They can, if wrappers are written. These wrappers were blocked by a maintainer.
Why? It needs to be in the kernel for new code to get written in Rust. Why can it only be in the kernel if the goal is to replace existing code?
They do!
This is where you lose me. I’m not a good programmer or a very smart person, but I have enough experience with c, c++ and rust to know that those wrappers don’t need to be in the kernel if the kernel has c bindings.
If I were writing something in rust I could just include the r4l wrapper for the kernels c bindings and everything would work fine. The wrapper doesn’t need to be in the kernel.
There’s a fundamental disconnect here. When people speaking about r4l including official statements from the r4l project say “our plan to add rust, a language intended to address shortcomings of c, to the kernel is only for new code, not a rewrite of existing systems.” I don’t believe them.
Not only do supporters of and contributors to the r4l project make offhanded remarks about how different things would be better if they were written in rust but if they truly believed in the language’s superiority to c then they would be trying to replace existing c code with rust.
Then the whole rust using and supporting world melts down when people oppose adding it into an existing huge c codebase.
Then they all complain that they’re being discriminated against for “nontechnical reasons”, which is becoming a great dog whistle for if you should just disregard someone’s opinion on rust outright.
Perhaps that explains some of why I don’t believe rust people when they flip out over not being allowed to do the thing that no one else is allowed to do either.
I think you have a fundamental misunderstanding of the topic.
We're talking about device drivers, which are part of the Linux kernel. If you develop these wrappers outside the kernel tree, you're making the situation even worse, since the kernel suddenly has a new dependency.
This approach was never considered, even by the maintainers that blocked wrappers, because it would be far worse than every other possibility.
Instead the question is: does every driver have to include a copy of the wrapper, or can there be one copy that's used by all the drivers? And obviously one copy makes far more sense than N different copies.
I'll skip over the rest of your comment, since it all seems to be built on a broken foundation.
Yes, literally include the wrapper code in every rust driver that needs it then when you push the wrapper on its own you can say “this code is currently duplicated 900 times because there isn’t a rust wrapper” not “this would make it easier for hypothetical rust drivers that might hypothetically exist in the future” and no one will bat an eye!
That’s how you get things added to the kernel!
If it was about adding rust code to the kernel, which is what r4l universally says they’re doing, then they’d be taking that approach instead of farting around with the chicken and egg problem trying to get rust everything first.
That’s the whole point of the part of my comment that you dismissed out of hand. They’re nearly universally behaving in a way that it takes actual concerted brainpower to read as anything other than duplicitous.
And then when people say “hey, why don’t you not act like that” you get responses like “Linus said we could!” And “nontechnical nonsense” and “Dino devs”.
I don’t think that’s a broken foundation.
That is what they are already doing and it's introducing unnecessary work! There's nothing about "hypothetical rust drivers", it's the case right now.
Weird, how come C drivers don't have to track these interfaces in their own trees? Why is this the way to get Rust code added to the kernel, but all other code doesn't have to jump through these hoops?
I’m not at a computer with the source on it, so if you get to it before me, how many rust drivers are there? How many that would use the rust dma wrapper?
I ask because last year there were relatively few.
People writing in c don’t have to use a wrapper because there’s no need to wrap c code for use by other c code.
More broadly there are times when duplicated c code has been condensed into a library or something and added to the kernel.
... of course there aren't many Rust drivers so far, since the project is still young, and it's evidently still facing hurdles and not really accepted by everyone. But if there's already a couple of Rust drivers and Rust has explicitly been accepted into the Kernel, we're already past your “this would make it easier for hypothetical rust drivers that might hypothetically exist in the future”, so why argue such irrelevant points?
And that's what has been blocked here...
They are not irrelevant points and hopefully I can show why.
So I went fishing through the kernel rust directory and didn’t find any drivers. It’s late and I definitely missed a lot (I didn’t even go through the drivers branch, but should rust code be there? I thought it all lived in /rust…), but the r4l page lists the nvme driver, an implementation of existing functionality in rust that is in the words of its description page “not suitable for general use”. The r4l page also has the null block driver, which is not a strictly speaking useful thing for actually doing stuff with the computer but is a great way to do a bunch of goofy crap and its page on the r4l website explains why it’s being rewritten in rust.
I just want to pause here in the comment and say that the null block driver is actually a phenomenal thing to be rewriting in rust for so many reasons.
Then there’s the android binder driver which is not something I understand enough to comment on, but is a rewrite in rust. I also saw a puzzlefs driver on the r4l page. Puzzlefs is an experimental file system written in rust to begin with so it’s no surprise the Linux driver is rust.
Last the r4l page offers two gpu drivers, the apple one that asahi uses and the nvidia nova one which seems to be in the early stages of development.
As I said, I probably missed some drivers and other rust code that needs to use —since it’s our topic of discussion— the c dma bindings through a wrapper.
But if all six of those used the dma c bindings wrapper then that’s still far short of my agreement with you that the right way would be to write a bunch of good rust shit that uses the wrapper then say “hey, if we move this wrapper into dma directly it’ll save 10k lines of code because it’s a hundred lines and used in a hundred things”.
Instead it’s used by three rewrites (the point of r4l!), an experimental file system, a in development gpu driver and the asahi mac driver.
For a third time, I’m absolutely 100% sure there’s more rust drivers than that, but enough to make the argument that you’re taking a hundred lines out of a hundred places?
When I was younger I was involved in local government. I was idealistic and thought that having been accepted at the table, the correctness of my ideas would be evident and they would be accepted and implemented quickly. Of course I was very wrong and was surrounded by competing interests vying for limited resources so the force of my argumentation had almost no effect.
What was effective was constructing scenarios that made it almost impossible for people to act in ways other than what I wanted.
I chose a narrative analogous to the common rust person complaint of “political reasons” here on purpose because ultimately instead of appealing to an authority to settle the chicken or egg problem for them (which is somehow not political, despite the authority existing within some governing structure but whatever!) rust devs should be saying “who the fuck cares, I’m headed to market with a cartload of chickens and eggs, you gonna give me a stall to sell out of or am I gonna be clogging up the thouroughfares?”
Sure there is! Maintain your own tree, like I said. Eventually, it'll be proven to be workable. Or not.
No, they aren't. They are blocking how it's being done, with R4L folks wanting to toss the maintenance headaches over the wall, for someone else to deal with, because they don't want to build their own C interfaces, that match the already existing ones.
Try to understand the problem better, so maybe you'll be able to understand why maintaining your own tree to prove the conceptual implementation works, and doesn't hand maintenance overhead to another party.
Why lie about something so easy to check? Here's the maintainer himself saying that the issue isn't "R4L folks wanting to toss the maintenance headaches over the wall, for someone else to deal with":
And, again, prove him wrong, maintain a tree that shows it's workable, and with minimum maintainability concerns. If there truly are minimal maintenance concerns, a separate tree would be quite simple to maintain!
For the last time, the decision to include Rust has already been made. The "prove him wrong by developing out-of-tree" has already happened.
Apparently, it hasn't happened. Because nobody else beside R4L is helping it along.
Sorry, but ya'll just have more work to do, is all. Do it, or don't, I don't care. I honestly don't care one iota if Rust ever gets in the kernel, or not. What I do care about is that the Linux kernel remains a stable project.
Take the advice, or don't. Its on you.
There's no advice to take for working with maintainers who'll abuse their power to stop a project they don't like.
Ok, so then just toss in the towel, and make your own kernel, with hookers, blow, and Rust. Sorry.
Because the only "power" maintainers have is over the Linux kernel tree. They have no power over your own tree you maintain, with your Rust team. They have no power over the Rust kernel projects already working.
Hell, they don't even have the power to keep you from taking their driver work, to build on! In fact, it's encouraged!
This may come as a shock to you, and other proponents of the R4L team: The world does NOT revolve around you, and your preferred development language.
Or I can ask Linus to do his job properly and lead on this issue, whether it's for or against R4L.
You seem to be under the impression that I'm somehow involved with R4L or Rust, or that I even use Rust. None of these are true. I'm just seeing an example of bad project management, and people like you that keep lying to justify the maintainers decision.
Linus owes you, nor anybody not signing his paycheck, a goddamed thing. Did you bother to read the article linked here?
Ok then.
Nobody committing code to the Linux project, nor anybody doing the administrivia work owes anyone not involved in the project a goddamned thing. If you think you can manage it better, then fork, and do it.
Otherwise, you're expecting other people to do free labor for you, and to do it to your specs. The world doesn't work that way, and nobody owes you their labor.
Labor does. Laying out demands on labor does nothing, unless you're the one meeting their material needs.
No, he owes the community to fulfill his role in this community project. He's not a king or a monarch or whatever you think he is. If he's not ready to fulfill this role, he should step down as project lead.
Not really. He owes nobody his labor. If people don't like how he runs it, they can fork, and run it as they please.
Of course he's not. And, neither are you. Neither of you can place demands on others to perform free labor.
Well, he thinks he is fulfilling his role. You don't. So, its up to you to show everyone how to do it right.
I've found most people who claim others "aren't doing it right" actually mean that "they aren't doing it how I want it to be done, and therefore I demand they do the work per my spec, even though I'm not meeting any of their material needs."