Comment by AshamedCaptain

> The natural reaction is that there will be less such breaking changes and interfaces will ossify. One can even argue this is what has already happened here.

I don't think I'd agree with that. Current kernel policy is that the C interfaces can evolve and change in whatever way they need to, and if that breaks Rust code, that's fine. Certainly some subsystem maintainers will want to be involved in helping fix that Rust code, or help provide direction on how the Rust side should evolve, but that's not required, and C maintainers can pick and choose when they do that, if at all.

Obviously if Rust is to become a first-class, fully-supported part of the kernel, that policy will eventually change. And yes, that will slow down changes to C interfaces. But I think suggesting that interfaces will ossify is an overreaction. The rate of change can slow to a still-acceptable level without stopping completely.

And frankly I think that when this time comes, maintainers who want to ignore Rust completely will be few and far between, and might be faced with a choice to either get on board or step down. That's difficult and uncomfortable, to be sure, but I think it's reasonable, if it comes to pass.

> You are adding a second layer of abstraction that brings very little generalization

Presumably, this is an investment in replacing code written in C. There's no way around abstraction or overhead in such a venture.

> there's no way it doesn't significant put additional pressure when making breaking changes

This is the cost of investment.

> The natural reaction is that there will be less such breaking changes and interfaces will ossify.

A) "fewer", not "less". Breaking changes are countable.

B) A slower velocity of changes does not imply ossification. Furthermore, I'm not sure this is true—the benefits of formal verification of constraints surrounding memory-safety seems as if it would naturally lead to long-term higher velocity. Finally, I can't speak to the benefits of a freely-breakable kernel interface (I've never had to maintain a kernel for clients myself, thank god) but again, this seems like a worthwhile short-term investment for long-term gain.

> In addition, depending on the skill of the "binding writer" (and generally, since the rust bindings are actually designed instead of evolving organically), the second set of interfaces may simply be actually easier to use. There may not even be a point to evolving one interface, or the other. Which just further contributes to splitting the project.

Sure, this is possible. I present two questions, then: 1) what is lost with lesser popularity of the C interface with allegedly less stability, and 2) is the stability, popularity, and confidence in the new interface worth it? I think it might be, but I have no clue how to reason about the politics of the Linux ABI.

I have never written stable kernel code, so I don't have confident guidance myself. But I can say that if you put a kernel developer in front of me of genius ability, I would still trust and be more willing to engage with rust code. I cannot conceive of a C programmer skilled enough they would not benefit from the additional tooling and magnification of ability. There seems to be some attitude that if C is abandoned, something vital is lost. I submit that what is lost may not be of technical, but rather cultural (or, eek, egoist), value. Surely we can compensate for this if it is true.

EDIT, follow-up: if an unstable, less-used interface is desirable, surely this could be solved in the long term with two rust bindings.

EDIT2: in response to an aunt comment, I am surely abusing the term "ABI". I'm using it as a loose term for compatibility of interfaces at a linker-object level.