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 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.
That’s how you get things added to the kernel!
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.
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?
… 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?
More broadly there are times when duplicated c code has been condensed into a library or something and added to the kernel.
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?”
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?”