Time to step up, Linus/GregKH

Posted Feb 5, 2025 15:52 UTC (Wed) by Wol (subscriber, #4433)
In reply to: Time to step up, Linus/GregKH by Wol
Parent article: Resistance to Rust abstractions for DMA mapping

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.