[zoogeny]

I'm just parsing the thread but it seems that changes to the C api can break the Rust bindings.

This leads to two situations: the C maintainer has to also update the Rust binding, or the patch has to wait for a Rust capable maintainer to fix them up.

For the first solution, the C maintainer is claiming he has enough work on his plate just keeping up with the C code that he doesn't want to work on Rust. He also believes it is unfair to force every C maintainer to learn enough Rust to keep their integration points working.

For the second solution, the C maintainer is pointing out that Linus has a history of refusing to merge C patches that break Rust builds. So even though the Rust advocates promise they will handle all of the Rust stuff and they are OK with their stuff being broken after C changes until they get around to fixing it, Linus doesn't seem to actually allow for this in practice.

I can see the maintainers point. Sooner or later Rust bindings on critical systems will be essential and changes to the C code will be gated on changes to the Rust code. It is a fantasy of the Rust maintainers that they will have to shoulder that entire burden. But even if they did, it would give them some pretty hefty leverage over the C maintainers in those essential cases. And it also introduces a requirement that someone with enough Rust and subsystem knowledge is even available for the job. People making promises today may disappear tomorrow, leaving the maintainer with an essential binding to a language he doesn't want to support.

edit: as has been said elsewhere, Linus could make some of this go away by committing to let the Rust builds break. I don't know if that could be done in a way that wouldn't be a de facto fork.

[steveklabnik]

> Linus could make some of this go away by committing to let the Rust builds break.

Linus already did that. This is the state of things today. C code is allowed to break the Rust, and it's the Rust for Linux people's responsibility to get it working again, not the C folks.

[zoogeny]

I'm just an interloper and only going on the linked thread, but there are specific patches that missed merge windows due to Rust build breaks. The patches referenced are claimed to be exceptions but I can understand the fear. Linus is saying one thing but making exceptions in some cases. As Rust becomes more and more integrated into core Linux systems those exceptions may become more frequent and may eventually become the rule.

To be fair, I think another valid solution to this problem is just to bite the bullet and tell the grumpy C developers to deal with it. At some point the fallout from an exodus of grey beard Linux maintainers will actually be less than fighting this battle. As many point out, they are going to exit the project one way or another eventually.

[steveklabnik]

> The patches referenced are claimed to be exceptions

From what I understand, this is correct, or at least that is, this was a build system bug that caused accidental breakage, not a deliberate change in the policy that the kernel must be able to be built with Rust support turned off, and that that is the build that matters. Exceptional in a "rarely happens" sense and not a "deliberate choice to create an exception to a rule" sense.

[XorNot]

This entirely depends on the supposition that there are more new kernel developers who want to, and are able to, use Rust then C.

I don't think this is proven: what we have is a specific group of Rust developers, but they are there by virtue of that group existing. There are numerous more kernel contributors today who work in C, and since the greybeards are happy to keep up the work it's not like anyone else is going to easily step in to replace them (since it would be a coup not a handover, if they didn't actually want to step down).

An equally plausible future is some such Rust mandate happens, you drive off the existing C developers, then it turns out the Rust developers aren't actually numerous enough or committed enough (or even good enough at long term project social management) to keep the project going and it dies (or forks into CLinux or something).

Linux itself was a "hobby project" which ultimately succeeded because it did the work which needed to be done, while everyone else was still completely sure the microkernels were the way of the future.

[ho_schi]

Thanks.

[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.