Comment by skerit
1 day ago
So if I understand correctly, Linus & co say no maintainer is forced to write or accept Rust code in their little piece of the kernel.
But maintainers claim that other people simply interfacing with their code through Rust bindings would require the maintainers to change that Rust code anyway if any changes they make would break those bindings? Am I getting that right?
The maintainer of the DMA subsystem, Christoph Hellwig seems to vehemently oppose having an mixed-language codebase, and is using the confusion whether he as a maintainer has a say against the consumers of his APIs, to further his cause.
There was indeed some confusion about this, because the normal rule of kernel development is that if you change an API, you also fix the downstream users. (A standard-ish monorepo rule.)
However, because R4L is an experiment, the rule seems to be different: it's up to the R4L team to fix the Rust side if things break, so the upstream C devs don't need to care about Rust if they don't want to. (And conversely, they can't then weaponize their reluctance against Rust. That blade cuts both ways!)
However, apparently there wasn't sufficient clarity about this rule. Well, now there is.
logistically, how would this work in a monorepo? if you merge an API change and don't fix downstream users, isn't the build broken for everyone? or is there a deprecation process where the old API remains functional for a period?
Rust is behind a flag that defaults off, so it's only broken for people who flip the flag.
1 reply →
Specifically, the reason Linus is lashing out here is that devs are claiming they want nothing to do with Rust, and then suggesting that that means they get to say Rust can't call their code.
e.g. what they really are doing, as Christoph explicitly admitted in the thread, is that they are attempting to relitigate whether you can use Rust at all in Linux, and convince people that it's so hard to work on that they just give up and go home.
In the end, for kernel users, yes. However, what he did is much larger IMHO: he addressed the utter blockade performed by the maintainer, that basically said no without any margin of negotiation.
In the end, he explicited that not wanting to touch Rust goes both ways: you don't want to touch Rust? Fine. But you lose all rights to complain about what others are doing with Rust.
In other words: don't be a jerk, and don't have selective involvement.
No, Linus is saying that to have a say, you have to stake something. You can't veto something and at the same time not engaging with it in any other constructive way. You either ignore it totally, or you don't and become part of the process. In this specific case, you do not get to decide who the client of your code/subsystem is, and the only way you have a say about it is by offering actual feedback about it.
I don't think that's true though, given the Linux development model where all internal APIs are private and unstable and can be changed at any time. It means there is a two-way dependency between API providers and users - because it isn't a public API you are allowed to change it, but you have to fix all the places it is used too.
If those places now include Rust then it would require you to learn Rust (or depend on other people).
Really they just need to make a decision at this point. Either Rust is allowed and maintainers are going to have to learn it, or there's no point and the Rust people are going to have to fork Linux.
I guess there is a third option: a stable driver ABI. But they've avoided that at all costs for years so I don't see it happening. And besides, Rust is going to be used for more than just drivers eventually.
> Really they just need to make a decision at this point.
They already _have_ made this decision. Why do people keep misunderstanding this. While ordinarily if you change the API you are required to change all of the callers of that API to match, in this one special case the maintainer of a module can declare that they don’t want to touch the Rust code and that if they change the API then they are not going to change the Rust code that calls it. In that case the Rust for Linux team will step in and make whatever changes to the Rust code are needed.
6 replies →
> I don't think that's true though, given the Linux development model where all internal APIs are private and unstable and can be changed at any time
Others have pointed out that this is mistaken, but also, it's in the link itself:
> So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't have to deal with Rust.
2 replies →
The argument being made was that the nominal rule is that the Rust side has to fix their things if the C side breaks them, but in practice it doesn't work that way, allegedly because Linus has NAKed patchsets that didn't have fixes for Rust being broken in them.
I would imagine the hopefully straightforward path would be to make sure the Rust code gets build tested, and then if that fails, have a route to reach out to the people who want to do R4L work and tell them "this is breaking because of what I changed, can you help when you get a chance", for the maintainers who don't want to learn Rust.
...of course, one reason the maintainers loathe this idea, is that the personality archetype who works on Linux generally is the kind of person who would go fix it themselves because they're impatient, so with that framing, it's pretty clear why they think "wait on other people to fix it" is a nonstarter de facto...
3 replies →
> So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't have to deal with Rust.
- Linus