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.
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.
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.
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.
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.
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.
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.
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?
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?
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.
Sure there is! Maintain your own tree, like I said. Eventually, it’ll be proven to be workable. Or not.
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.
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.
I don’t know how to better explain this to you.
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”:
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.
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!
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.
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!