If you read the article, the main issue is not the fact that it’s Rust itself, but that it’s a second language entering the codebase. There’s definitely some validity to the argument.
My personal view is that any C developer who doesn’t want to learn Rust is going to kick themselves once they do.
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!
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.
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.
General idea seems to be “keep your glue outside of core subsystems”, not “do not create cross-language glue, I will do everything in my power to oppose this”.
Nobody asked for the code to be maintained by DMA. The maintainer blocked a PR outside his subsystem, and even if it was part of his subsystem, the R4L approach is that C developers can break Rust code however they want.
Literally nobody suggested that the DMA maintainers should maintain Rust code.
To be fair, I’m not sure how “I will do everything in my power to oppose this” is the anti-Rust side “work[ing] towards some resolution”…
deleted by creator
If you read the article, the main issue is not the fact that it’s Rust itself, but that it’s a second language entering the codebase. There’s definitely some validity to the argument.
My personal view is that any C developer who doesn’t want to learn Rust is going to kick themselves once they do.
Sure. But I’ve seen quite a bit of push back against rust from these sorts even outside the kernel.
They specifically name and shame rust as the shiny new language of the day. It does make it seem like a personal grudge against rust specifically.
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!
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.
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.
https://lore.kernel.org/lkml/[email protected]/
General idea seems to be “keep your glue outside of core subsystems”, not “do not create cross-language glue, I will do everything in my power to oppose this”.
This creates a lot of extra work for no benefit, as every driver that needs DMA would have to include their own copy of the DMA stuff.
They still can share code. Just not maintained by dma.
Nobody asked for the code to be maintained by DMA. The maintainer blocked a PR outside his subsystem, and even if it was part of his subsystem, the R4L approach is that C developers can break Rust code however they want.
Literally nobody suggested that the DMA maintainers should maintain Rust code.
Huh.