People can just include their own dma.rs in driver/.../mydriver/
Whether that's a good or bad approach is besides the point. It's what was suggested as an alternative, and clearly it's something that would work. "You can't use DMA from Rust" is just not true.
If it was a good approach, the C folks would have copied around C files instead of having common core code. They did not do that though, because it'd be counter productive due to increasing maintenance burden.
Everyone knows it would increase maintenance burden, decrease reliability, and increase the amount of apparent churn of rust code in the linux kernel.
Everyone knows you could start the crude way today and refactor the duplication later after it proves itself, if you actually wanted to proceed rather than throw fits.
And after that driver is in use for a while and a million users all depend on it because it works so good, other developers will all on their own start asking "why are we diing this this stupid way? I think the original argument is no longer valid, or we can see now that it never was valid. We should revisit that."
Or as more rust devs work on more modules that each need some similar redundant boilerplate, a larger number of individual devs who each ask the same "hey, can we please get at least this level of concession to have a shim somewhere we can interface with instead of all this fragile tight coupling?" When that grows to become a respectful request from many, including users, instead of a disrespectful demand from a few, you get a different result.
But that is step 2. The opportunity for step 2 sometimes simply will not exist without first going through a step 1.
You want in? Yes but the terms are shitty. Yeah, so, you don't want in? It's obviously OK with most of the kernel devs if the rust devs decide this is not rewarding and go away. They are not eagerly welcoming to this particular development. And they don't have to be. How welcoming would rust developers be to c developers demanding to rewrite cargo in c? Go work on redox and make it so great it takes over and replaces linux by simply being the better choice while being equally free and at least as well managed and clearly visioned.
I don't know the better way to ask this question, so I'm just going to ask it:
"Congratulations, you're right, and nobody cares."
Now what? Just complain that the kernel isn't hospitable to Rust, and hope 15 years from now we're all using some Linux-compatible kernel built ground-up in Rust?
I genuinely want to know where you go from this position.
I am trying to explain why someone would say this.
I think Rust in Linux makes sense, but honestly, Rust doesn’t need Linux to be successful, and I barely use Linux personally. If they decide Rust for Linux is not a thing, that’s for the folks who work on and care about Linux to deal with. This isn’t my fight, I am just observing.
I’ve been primarily a Windows user for many years now, but I do use some WSL. My main OS is already shipping Rust, and in the actual kernel, without all of this wailing and gnashing of teeth. (That said I respect the approach Linux is taking here, I don't think it's inherently bad.)
Oh, and honestly, what I believe is happening here is just that, from Linus's perspective, folks should know that because this isn't in Hellwig's part of the tree, his NACK doesn't actually matter, and he'll just end up pulling this patch in anyway. There's no need to intervene because there isn't actually obstruction going on. The internet is just going wild about this drama because they fundamentally misunderstand how kernel development works, and because people are slinging mud on the LKML. That's why he only commented on Hector's behavior.
I can see that perspective, though I would prefer a different management style, but that's also why (among other reasons) I don't care to contribute to the kernel.
DMA is needed for an overwhelming number of useful drivers.
If you can’t use DMA from Rust, then you can’t really properly evaluate the usefulness of Rust, hence the effort is basically dead.