this post was submitted on 13 Feb 2025
334 points (97.7% liked)
Linux
50396 readers
886 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?
Let me just say that hierarchies are for breaking ties.
The normal process is that Linus prefers we all work through maintainers to cut down on the noise that comes to him. In this case, the maintainer is the reason the noise is coming to Linus. So, it will be up to him to settle 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/20250131075751.GA16720@lst.de/
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?
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?
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.
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.
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.