80
you are viewing a single comment's thread
view the rest of the comments
[-] Cypher@lemmy.world -3 points 2 days ago

Hellwig has some excellent points and people are up in arms solely because he’s not giving the green light for the shiny new toy.

Keep the wrappers in your code instead of making life painful for others

This is a perfectly valid approach, anyone claiming he’s resistant for no reason has never tried maintaining a multi language code base.

If you want to use something that's not C, be that assembly or Rust, you write to C interfaces and deal with the impedance mismatch yourself as far as I'm concerned.

Again an entirely reasonable approach. There is precedence for this approach in the kernel/dma and I see no reason to change this now, unless a full kernel/dma rewrite to Rust were to occur.

[-] edinbruh@feddit.it 19 points 1 day ago* (last edited 1 day ago)

What they are asking is not to change the c code to suit rust, but to leave the C code as is, and have a single Rust-written wrapper that links into the C DMA code so that other Rust drivers can link into the wrapper. Additionally, said wrapper is not to be maintained by Hellwig, but by the maintainers of the drivers that will use the wrapper, so without overhead for Hellwig.

He is not asking to not make his work harder, he's explicitly asking to make it harder to write rust drivers that use DMA.

[-] Cypher@lemmy.world -5 points 1 day ago* (last edited 1 day ago)

So you think Hellwig doesn’t understand what is and isn’t intended to go into the kernel/dma that dma maintainers would then be responsible for?

You don’t seem to be familiar with either the full conversation the developers had (its all available) or you don’t understand how the Linux project is structured and maintained.

From the email chain:

On Thu, Jan 16, 2025 at 02:17:24PM +0100, Danilo Krummrich wrote:

Since there hasn't been a reply so far, I assume that we're good with maintaining the DMA Rust abstractions separately.

No, I'm not. This was an explicit:

Nacked-by: Christoph Hellwig

And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-languagecodebase and not rust itself, just to escape the flameware brigade).

[-] edinbruh@feddit.it 3 points 20 hours ago

I think Hellwig understands everything very well, he just wants things done his way, for whatever (possibly valid) reason he might have.

Literaly from your quotation: "I assume that we’re good with maintaining the DMA Rust abstractions separately [...] No, I'm not" He understands the abstractions would not be in his domain and maintained by someone else, he does not want abstraction at all.

Maybe you are not familiar with the proposal but these "separate rust abstractions" would be a separate module that depends on DMA mapping as a client and deals with cross-language issues, rust drivers would then be clients of this module, it would not be part of the DMA mapping module, it would not be mixed with the DMA code. But Hellwig doesn't want an abstraction module at all, Instead he want's you to "do that [the abstraction] in your driver so that you have to do it [maintain a cross-language codebase]".

Please notice that the abstraction module would not add any more burden on him than the drivers themselves would, because as of now C code is allowed to break Rust code. It would only remove burden from maintainers of Rust drivers, and even if it weren't it would be easier to fix just the abstraction instead of every driver.

He also refuses to have other people maintain the abstraction, this too for whatever reason, which accredits his request to not add abstraction he would have to maintain. If the abstraction were part of the core dma mapping code, I think it would be a reasonable request, but it wouldn't be.

Now, we do not know the reason why he opposes it so much. From his words it looks like he doesn't want Linux to be a cross-language codebase, which would be a valid reason in itself, but dealing with abstractions in drivers instead of a module doesn't make it any less cross-language, unless the drivers are out of tree, which they wouldn't be. Some people (e.g. Hector Martin) think that he's hoping the Rust for Linux project to fail altogether, and fore rust code to be removed from the kernel, and this obstruction would partake in that. I do not think it is that drastic, I think he just fears that those abstraction would eventually become part of what he has to maintain, and no amount of reassurance or new maintainers would change his mind.

I also don't think Martin's brigading is anything productive, and I hope that doesn't become the reason that rust code gets obstructed from being merged into the kernel, but it sure does focus the attention on these matters.

[-] Corbin@programming.dev 5 points 1 day ago

Martin's already in the list of maintainers for another subsystem; this is a territorial play by Hellwig. Any kernel developer would recognize this; you don't seem especially familiar with kernel social dynamics either! Also please fix your formatting if you're going to copy-and-paste rather than linking.

[-] Cypher@lemmy.world -1 points 1 day ago

Martin is not a maintainer of the Kernel/DMA which is why Hellwig clearly states he doesn’t want to add another maintainer when rejecting Martin’s offer to be a maintainer of this proposed code.

This is very clear if you read the email. If you don’t like the formatting go read the full email chain yourself, you will know where to find it if you’re so familiar with ‘kernel social dynamics’.

this post was submitted on 06 Feb 2025
80 points (97.6% liked)

Linux

5869 readers
372 users here now

A community for everything relating to the GNU/Linux operating system

Also check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 2 years ago
MODERATORS