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?
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.
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.
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.
I think you have a fundamental misunderstanding of the topic.
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.
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.
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!
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.
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.
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.
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.