The context is that hellwig doesn’t want another maintainer or deal with a split codebase in the dma subsystem which I honestly agree with.
If I were a maintainer in that position I’d be barring the doors too. It’s not a driver for some esoteric realtek wireless card or something.
Even if I didn’t agree with that position it’s normal to only post on the kernel mailing list about shit you actually care deeply about because it’s public and aside from all your fellow devs taking the time to read what you wrote, psychotic nerds like myself watch it and will try to read the tea leaves too!
If I were a maintainer in that position I’d be barring the doors too. It’s not a driver for some esoteric realtek wireless card or something.
This effectively kills R4L. If they can’t include Rust Interfaces for important subsystems, each driver written in Rust that uses these subsystems has to separately track all the Subsystem Interfaces, leading to lots of extra work for no benefit.
If this is the approach Linux takes, they should just cancel R4L completely.
Sure, I don’t think it’s like toxic or anything, but I also understand why Martin viewed the situation as an impasse requiring a decision from on high. Also, from my limited understanding it sounds like the new code was in a sequestered rust-only section of the dma subsystem, so I’m not clear on exactly what new burdens were being placed on the C dma maintainers.
My understanding is that the rust code in question implemented parts of the c dma interface so that rust programs could use that instead of the c dma interface.
I’m out in the world, not sitting in front of a computer with the source open so that guess will have to do for now.
The most immediate problem with having two different dma interfaces is that now you have two maintainers and an extra step at best when making any changes.
That’s tame for the kernel mailing list lol.
The context is that hellwig doesn’t want another maintainer or deal with a split codebase in the dma subsystem which I honestly agree with.
If I were a maintainer in that position I’d be barring the doors too. It’s not a driver for some esoteric realtek wireless card or something.
Even if I didn’t agree with that position it’s normal to only post on the kernel mailing list about shit you actually care deeply about because it’s public and aside from all your fellow devs taking the time to read what you wrote, psychotic nerds like myself watch it and will try to read the tea leaves too!
This effectively kills R4L. If they can’t include Rust Interfaces for important subsystems, each driver written in Rust that uses these subsystems has to separately track all the Subsystem Interfaces, leading to lots of extra work for no benefit.
If this is the approach Linux takes, they should just cancel R4L completely.
Sure, I don’t think it’s like toxic or anything, but I also understand why Martin viewed the situation as an impasse requiring a decision from on high. Also, from my limited understanding it sounds like the new code was in a sequestered rust-only section of the dma subsystem, so I’m not clear on exactly what new burdens were being placed on the C dma maintainers.
My understanding is that the rust code in question implemented parts of the c dma interface so that rust programs could use that instead of the c dma interface.
I’m out in the world, not sitting in front of a computer with the source open so that guess will have to do for now.
The most immediate problem with having two different dma interfaces is that now you have two maintainers and an extra step at best when making any changes.