[tux1968]

That's up to the maintainer; if they don't have any knowledge of Rust, then it's better they don't get involved anyway. They're still responsible for designing the best C interface to their subsystem as possible, which is what most of the kernel will be interacting with. It puts the burden firmly on the shoulders of the Rust advocates; who believe the task is manageable.

As for your concern about code quality, it's the exact same situation that already exists today. The maintainer is responsible for his code, not for the code that calls it. And the Rust code, is just another user.

[macspoofing]

>They're still responsible for designing the best C interface to their subsystem as possible, which is what most of the kernel will be interacting with.

What if you're in a world where Rust code is either a significant or primary consumer of your interface ... surely as the API designer, you have to take some interest in how your API is consumed.

I'm not saying you become the owner of Rust bindings, or that you have to perform code-reviews, or that you have veto power over the module .. but you can't pretend Rust doesn't exist.

[pornel]

Giving good feedback about Rust<>C bindings requires knowing Rust well. It needs deep technical understanding of Rust's safety requirements, as well as a sense of Rust's idioms and design patterns.

C maintainers who don't care about Rust may have opinions about the Rust API, but that's not the same thing :)

There are definitely things that can be done in C to make Rust's side easier, and it'd be much easier to communicate if the C API maintainer knew Rust, but it's not necessary. Rust exists in a world of C APIs, none of which were designed for Rust.

The Rust folks can translate their requirements to C terms. The C API needs to have documented memory management and thread safety requirements, but that can be in any language.