Time to step up, Linus/GregKH

Posted Jan 31, 2025 16:42 UTC (Fri) by dralley (subscriber, #143766)
In reply to: Time to step up, Linus/GregKH by LtWorf
Parent article: Resistance to Rust abstractions for DMA mapping

This has not happened. If you are referring to what I think you're referring to, you are misrepresenting the situation completely.

In the case with Wedson, the fact that a roomful of kernel developers argued without agreement for several minutes on the precise semantics of the existing C APIs is precisely evidence that such semantics need to be thoroughly documented - which was all the Rust developers were asking for. If it's so complex that the foremost experts in the world can't remember exactly how it works, then it's very hard to take seriously the opinion that "everything is fine, no need to write it down for posterity".

In the case with Asahi Lina, that was over code that was *broken* with or without Rust, the issues would have been visible even with a pure C driver, but the maintainer was rejecting her opinion on the basis of being a "Rust person talking about lifetime issues" despite this.

In both cases the oppositional stance of the maintainers is extremely difficult to make sense of from a purely-technical standpoint.

Time to step up, Linus/GregKH

Posted Feb 5, 2025 7:28 UTC (Wed) by qtplatypus (subscriber, #132339) [Link] (5 responses)

What was the eventual outcome of the Asahi Lina patch’s?

Time to step up, Linus/GregKH

Posted Feb 5, 2025 9:46 UTC (Wed) by Wol (subscriber, #4433) [Link] (4 responses)

From what I know, the C maintainer was being perfectly reasonable. Asahi was being perfectly reasonable. For whatever reason they just didn't hit it off with each other and got stuck in a slanging match.

Someone higher up stepped in, knocked their heads together, and said "we need to keep these two apart". Then everything got sorted.

Sometimes two people just don't get on. I've had people I can't stand. It happens. It got sorted.

Cheers,
Wol

Time to step up, Linus/GregKH

Posted Feb 5, 2025 14:55 UTC (Wed) by dralley (subscriber, #143766) [Link] (3 responses)

The C maintainer wasn't being entirely reasonable - Lina was pointing out flaws in the C code that could be encountered even from C-written drivers.

Eventually she gave up and wrote her own scheduler in Rust to avoid having to deal with drm_sched.

Time to step up, Linus/GregKH

Posted Feb 5, 2025 15:46 UTC (Wed) by Wol (subscriber, #4433) [Link] (2 responses)

And as I understood it (and not from the other party - but from a respected kernel maintainer here), the C guy was entirely reasonable.

It's a long way from saying "but that is an obvious bug in the C code", to getting to "and this is a fix *that*will*not*cause*spaghetti*breakage*where*you*least*expect*it*". And THAT is what Lina just could not get!

I'm not going to come down on either side, but I've had plenty of experience of an "obvious" fix going subtly and disastrously wrong, so I can sympathise with the C guy. I'm dealing with this right now at work - a colleague didn't bother to understand the subtleties of some tricky code, put in a fix of her own that happened to work (breaking the overarching design of the original code), and now things have changed again we're having to bodge something, that should have been simple, to avoid breaking her code. All because what was meant to be a simple and clean - *and* *reversible* - design was bodged, and despite having forseen that we would want to back it out, we now can't because these bodges rely on it being present when it really should not be!

Cheers,
Wol

Time to step up, Linus/GregKH

Posted Feb 5, 2025 15:52 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

To reply to myself, have you ever heard the saying "if it ain't broke, don't fix it"?

Yes the C code was broke - for ONE person. And if I know the design of the code, I will quite happily dig in and refactor *my* stuff. But as soon as I start digging in other peoples' code, I'm a lot more cautious.

Lina has a compiler that helps her and alerts her much more to potential screwups. The C guy gets precious little help from the compiler - he doesn't want to get burnt where a "simple" change compiles just fine (but wrong) and then blows up in someone *else's* face.

Cheers,
Wol

Time to step up, Linus/GregKH

Posted Feb 5, 2025 21:26 UTC (Wed) by dralley (subscriber, #143766) [Link]

It wasn't broken for "one person", though. Christian König repeatedly agreed that the behavior was problematic, but kept falling back on how it was "as designed" and how the problems were known when it was designed, but everything was designed around that anyway.

See her comments here and the ones from Christian she was directly responding to:

https://lore.kernel.org/lkml/7e53bc1f-7d1e-fb1c-be45-f03c...

And David Arlie dropping in on a second discussion thread w/ Christian and Lina (those comments also worth reading)

https://lore.kernel.org/lkml/CAPM=9txcC9+ZePA5onJxtQr+nBe...

Now, I'm not entirely unsympathetic with Christian. From the standpoint of how things currently are, there's quite a lot of code written around the broken core abstractions, and un-breaking those abstractions is a lot of work. But the problems she was hitting were real, they were acknowledged, and the existing scheduler was not in any way "simple" as you claim it to be - and it doesn't seem like there was much motivation to fix those things. Hence Lina deciding it wasn't worth the time investment.

Time to step up, Linus/GregKH

Posted Feb 18, 2025 9:42 UTC (Tue) by daenzer (subscriber, #7050) [Link] (2 responses)

> In the case with Asahi Lina, that was over code that was *broken* with or without Rust, the issues would have been visible even with a
> pure C driver, but the maintainer was rejecting her opinion on the basis of being a "Rust person talking about lifetime issues" despite this.
>
> In both cases the oppositional stance of the maintainers is extremely difficult to make sense of from a purely-technical standpoint.

I respectfully disagree that these two cases can be classified the same like that.

The case with Asahi Lina was about technical issues[0]. Raising technical issues in proposed patches is the job of a maintainer. No DRM maintainer said anything like "I don't want Rust in the kernel" or "Rust is cancer".

[0] You're right that the same issues might have affected C patches, and they would have been raised the same way then. In fact, similar issues were raised in C patches many times before.

Time to step up, Linus/GregKH

Posted Feb 19, 2025 10:27 UTC (Wed) by smurf (subscriber, #17840) [Link] (1 responses)

> The case with Asahi Lina was about technical issues

Yeah, well, that's the point: the case *was* about technical issues, those being that adding the Rust bindings uncovered ambiguities and whatnot in the C interface.

But when a maintainer then refuses to engage with the reporter (and instead replies with the kernel ML's equivalent of the "Everything's fine" meme GIFs that's ubiquitous on the 'net) the case ceases to be a *technical* problem in the strict sense of that word.

Time to step up, Linus/GregKH

Posted Feb 19, 2025 13:53 UTC (Wed) by daenzer (subscriber, #7050) [Link]

> Yeah, well, that's the point: the case *was* about technical issues,

The text you quoted from my previous comment was in response to "the oppositional stance of the maintainers is extremely difficult to make sense of from a purely-technical standpoint". If a maintainer raising technical issues in patches is "difficult to make sense of from a purely-technical standpoint", maintainers might as well pack up and go shopping.

> those being that adding the Rust bindings uncovered ambiguities and whatnot in the C interface.

Don't think they really "uncovered" anything, the maintainer was already aware of the issues and explained them to the patch author.

> But when a maintainer then refuses to engage with the reporter (and instead replies with the kernel ML's equivalent of the "Everything's fine" meme GIFs that's ubiquitous on the 'net) the case ceases to be a *technical* problem in the strict sense of that word.

Having witnessed that discussion first-hand, I disagree that the maintainer refused to engage with the patch author. There was clearly a communication breakdown, the maintainer isn't solely responsible for that though. Communication is a two-way street.

Do you have a reference to back up the "Everything's fine" claim? My recollection is more like "the patches can't be merged due to these issues", which doesn't imply "everything's fine".