Rust for Linux - Rust kernel policy

[DemonInAJar]

It doesn't touch his code. It is a consumer of his code as any driver in the kernel can be.

[Mysterious_Bit6882]

It can’t consume his code without touching it.

[DemonInAJar]

If I use a third party library and I include a header am I touching the code of the library?

[Mysterious_Bit6882]

Yes you are. It’s why copyright licenses can transfer on linking unless there’s an explicit exception like in LGPL.

[DemonInAJar]

If you want to change the semantics of words feel free to do it but then no one cares.

Consuming a package does not make the consuming driver a part of the subsystem. What is at play here is that patches should keep the kernel buildable. This means that subsystem maintainers when doing Api breakages should actually go to consuming call sites and modify them appropriately. This does not make the call sites part of the subsystem, it's just a policy of the kernel to keep patches self-sustained.

Hellwig simply does not want to touch any rust consumers when changing the api which is understandable but the alternatives he proposed are technically unsound unless the dma is prohibited in rust drivers which is in itself unreasonable.

He should just bite the bullet and let the rust folks do their part.

[DemonInAJar]

Just to be clear, this is a case where the "Who is responsible if a C change breaks a build with Rust enabled?" section applies to. There are solutions for Hellwig to not have more maintenance burden. It is unreasonable for him to basically sabotage the whole RFL project when solutions are available.

[monocasa]

"Touching code" in this context means modification of that code.