Comment by SXX
10 months ago
The reason patch got rejected is super simple: because this wrapper not lives in specific driver and depends on DMA subsystem internal API.
And this cause problem. When someone make any change to Linux kernel they suppose to fix all the code they break across all kernel. And if said wrapper accepted then maintaner of DMA will have to make sure that all patches he accepts also fix Rust parts.
So he just dont want extra burden for himself.
> because this wrapper not lives in specific driver and depends on DMA subsystem internal API.
if multiple rust based drivers all need to have DMA support, what should they do? each come up with their own little magic?
> And this cause problem. When someone make any change to Linux kernel they suppose to fix all the code they break across all kernel.
this has been explained like 10+ times in this thread - it was made crystal clear to the DMA maintainer that he/she doesn't need to maintain the rust stuff, it is totally okay to break it.
> So he just dont want extra burden for himself
he can just resign. simple and period. no one is ever forcing him/her to be the maintainer when he/she is literally forcing other people to stop developing Linux support for the only powerful & affordable ARM machine for home use.
> what should they do?
Sorry to ask, but couldn't it be solved with cargo? I hear all the time about the benefits of Rust tooling and zero-cost abstractions.
Why can't a driver just pull/include the latest-dma-bindings crate and glue the gap with zero-cost abstractions?
If kernel DMA code/API changes, then nothing breaks in the kernel (hopefully) and the "Rust devs will quickly solve the changes" theory can be really proven and tested by quickly updating the bindings AND the updating the drivers.