[macspoofing]

As a C maintainer, you should care how the other side of the interface is implemented even if you're not actively involved in writing that code. I don't think it is reasonable, for software quality reasons, to have a policy where a maintainer can simply pretend the other side doesn't exist.

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

[bluGill]

That puts far too many chefs in the kitchen and worse(!) dilutes your time and understanding of the part of the code you know well. You need to trust your fellows in other areas of the code to make good decisions without you, and focus on what you know. Let other people do their own job without micromanaging them. Spend your time in your own lane.

Sometimes the other team proves incompetent and you are forced to do their job. However that is an unusual case. So trusting other teams to do their job well (which includes trying something you don't like) is a good rule.

[MontagFTB]

The API is the contract boundary. As long as it is well documented and satisfies its postconditions, it can be implemented in anything. Computing thrives on layers of abstraction like this.

[dralley]

Sure, and that's ideal for the maintainers that are willing to do that (and there are several), but for the C devs that just don't care and can't be forced to care, this is a pragmatic compromise. Not everyone has to be involved on both sides.

[macspoofing]

>this is a pragmatic compromise.

Yes. This is exactly what it is. It is a "pragmatic compromise" to side-step major internal cultural and philosophical issues (not technical issues). You're basically telling a number of C maintainers that they can simply pretend Rust doesn't exist, even if it may be the case that Rust code is the primary consumer of that API. That's a workable solution, but it isn't an ideal solution - and that's a little sad.

[bena]

You should care that it is usable, but how they use it should not concern you. If someone wants to use the usb driver to interface with a coin motor to build vibrating underwear, then that's none of your business. Your concern is if your driver works to spec and can be interfaced.

So if someone wants to write software in Rust that just uses the DMA driver, that should be fine. Linus is entirely in the right.

[macspoofing]

>You should care that it is usable

Yes. And that involves not completely ignoring an entire universe of consumers of your API, *as a general policy*. This is especially true with modules that may have Rust code as the primary consumer of the API.

I admit, I don't know what not ignoring Rust code by maintainer means in practice, and I agree it shouldn't mean that the C maintainer code-reviews the Rust bindings, or has veto power over the entire Rust module, or that the maintainer vets the architecture or design of the Rust module, or is on the Rust module mailing list. But it also shouldn't be that as a *general policy*, the C maintainer does not take any interest in how the API is consumed by Rust, and worse, pretends Rust doesn't exist.

>So if someone wants to write software in Rust that just uses the DMA driver, that should be fine.

That part is sensible. Did I argue otherwise?

[bena]

I think there's a fundamental disconnect here and I'm not sure if I quite see it.

It seems to me as if you're speaking about a hypothetical scenario where Rust needs something from the interface that isn't required by other languages. And you can't articulate what that might be because you can't think of an example of what that would look like. And also, in this scenario, Rust is the primary user of this driver interface.

But if that's the case, it's getting really close to "if things were different, they'd be different". If that's not the case, then I don't understand your case.

There's nothing wrong with the interface. Rust can use it just fine. It doesn't do anything C code wouldn't. They're not even asking for anything from what I can see. The person who maintains the DMA driver doesn't want Rust _using_ his interface, he's rejecting PRs where Rust code is interfacing with his driver.

The closest analogy I can think of is he wrote a book, but he doesn't want left-handed people to read it.

The API maintainer should only be concerned how the API is consumed in only that it is consumable and doesn't cause unintended side effects. And neither of those should be impacted by the language used to consume the API.

[tremon]

Did I argue otherwise?

You didn't, but Christoph Hellwig did -- which is what started off this whole kerfuffle last week.

[renewedrebecca]

> If someone wants to use the usb driver to interface with a coin motor to build vibrating underwear

starts writing business plan while installing CMake

[mmis1000]

Punch the hole though interface is a bad idea. And probably the worst one you can do. You 'should' just ignore the other side of the interface. And if that don't work. Fix the issue there (by yourself or find the code holder) instead of try to workaround from your end. Or if it always require change on both end, it's a hint that your interface isn't designed properly (thus always glue the the end together instead of separate it).

I hate it so much when people assume they are smart and workaround issue at other end of interface. It always end up that you need to understand both the workaround and original bug or you can't even read it.