[dralley]

No, the point is nonsense. Rust is a consumer of the APIs just like every other driver / subsystem is. Any change to the C APIs would likely require collaboration with those other maintainers no different than Rust. And CH would be immediately shut down if he tried to roadblock some random driver that needs DMA purely because he doesn't want the existence of that driver to "increase his workload".

[zoogeny]

I think you are using inflammatory language by calling the point nonsense.

As an outside observer, literally no skin in this game, I can see his point. If his C code changes breaks other C code then he is at an advantage compared to if his C code breaks a Rust binding or Rust drivers. The degree to which this adds to his burden of maintenance is up to him to decide.

[dralley]

The kernel is extremely complex. He very likely still needs to work with other maintainers if his code breaks their code. In this case he has LESS work to do, because the R4L developers own all fixes to Rust code, and he is free to break them, and they have to clean it up themselves.

[zoogeny]

The complexity of kernel isn't relevant, unless your point is that the kernel is already so complex that maintainers shouldn't advocate against new and significant complexity?

As for less work, that is alternative two from my original post which states the maintainer now has to wait for someone else to do the work or risk his change being stalled (worse case: indefinitely). It doesn't matter if the R4L team promises that they are OK with broken Rust code since the only person whose decision matters is Linus. Until Linus clarifies his stance on broken Rust builds the promises of the R4L team are promises that they are literally incapable of delivering on.

[steveklabnik]

It's nonsense because if his C code breaks the Rust binding or drivers, that is not his problem. It adds zero maintenance for him.

[alchemio]

But it does. He has to notify R4L of what his changes were and how it broke the Rust driver. Even if he didn’t, he will still be contacted for information regarding these things.

[steveklabnik]

He does not have to notify them.

> he will still be contacted for information regarding these things.

Just like any other user, and he is free to ignore them just like any other person doing so.

[dralley]

How is that different from any C driver currently in existence? Notifying API consumers of what is changing and how and answering the occasional is absolute table stakes for any software developer and throwing a tantrum about that is incredibly juvenile.

[FridgeSeal]

How is that literally any different from C code?

There’s 2 kinds of scenarios here:

- Rust code involved: C code change breaks Rust. ~Send~ ~an~ ~email~ ~and~ move on.

- C code involved: inform other C devs, either work with them or wait for them to fix.

The way I see it, either way, the “Rust stuff adds unacceptable amounts of workload” doesn’t really check out.

Edit: turns out he doesn’t even need to inform the Rust devs.

[nicce]

> some random driver that needs DMA purely because he doesn't want the existence of that driver to "increase his workload".

This isn’t blocking any drivers. Just adds duplicate code.