@gregkh Actually I can buy my own, what I'd really like is for us to kill nommu. It has zero reason to exist, and it's largely untested garbage.
Forget the booze, that's what I want.
@axboe @gregkh @ljs @vbabka yes, I did read https://lwn.net/Articles/1068928/ ; it does seem bittersweet though.
@Aissen @gregkh @ljs @vbabka Ah had not even seen that. It's not bitter sweet, removing code is a Good Thing, and now there's finally a reason to do it that carries some weight. Before this ordeal, it was always punted with "ah well the maintenance burden isn't THAT big". Kill it with fire, git history is forever and if someone steps up to properly maintain a piece of code, it can be brought back.
We're not running a museum.
@axboe @Aissen @gregkh @vbabka I already tried this, nommu is untested garbage and a hack and I hate it.
https://lore.kernel.org/linux-mm/77ab71c7-3608-4636-a618-3044c2316a92@lucifer.local/
hch of all people said:
"Nommu is a long standing and reasonable
well maintained part of the kernel, why would anyone want to kill it
for no good reason? I know quite a lot of products shipping it."
https://lore.kernel.org/linux-mm/20241122121826.GA26024@lst.de/
Also read this - https://lore.kernel.org/linux-mm/639c273e-0652-4d25-8385-fdddd7d1de78@wdc.com/
I mean honestly I'm surprised Linus allowed a new nommu arch in, and I'd rather we dump all of them.
It's a big maintenance burden, it's untested, and nobody anywhere has the slightest interest in improving any of that.
@david maybe we should isolate it to some section of maintainers (and out of one of mine ;) and treat it the way it deserves to be treated...
Yeah other than that fine with it π€£
@axboe @hyeyoo @vbabka @gregkh @Aissen if they can't explain it in detail themselves, then said reports should be dismissed imo
I mean there's a blurry line when you yourself confirm the report I guess.
But no credit unless you can explain it all, in detail.
Sloppers rarely respond much after you ask this kind of stuff :)
@hyeyoo @axboe @ljs @vbabka @gregkh @Aissen But it's adding a dominance signal!
Signal Standard Action Comment
βββββββββββββββββββββββββββββββββββββββββββββββββββ
SIGDOMINANCE Instinct Shriek Social dominance.
Chest-drumming may
be also accepted
in some domains.
*** SHRIEK! ***
@Aissen @gregkh @ljs @vbabka And let me just add, if you're not able or willing to do any work on this, your opinion on whether or not some code should be removed or stay in the kernel is worth absolutely nothing. Just stay silent, accept the decision of those that ARE carrying this maintenance burden.
@axboe @Aissen @gregkh @vbabka yeah I didn't push that all that much because hch isn't a bullshit artist and has done a lot to deserve respect even if he's fantastically wrong there.
But tbh I should have said that.
git log --author="hch" mm/nommu.c gives me a bunch of cleanup patches that happened to touch the file.
Oh and some work from 2015 :)
@hyeyoo @axboe @ljs @vbabka @gregkh I was mostly commenting on the context of network drivers being removed. A modern distro kernel ships those old unmaintained drivers and would allow retro-computing with 3com 3c589 card. Maybe the term isn't well chosen, but Linux got the reputation of having so many drivers, maintained for so long. But every good thing must come to an end.
@Aissen @hyeyoo @ljs @vbabka @gregkh The retro argument is quite typical. Someone should setup a retro tree and maintain it, those drivers and nommu (and 486 support!) can live there. There's zero reason to keep purely retro support in the kernel imho - if it hasn't been sold in products in decades, it need not be in the mainline tree.
@gregkh stupid question that is not asked enough:
do you think that the way rust can describe and enforce state machines and complex states/types, would generally force to build better architecture?
Or, the lack of (in)adaptability of the system will be more problematic in the long run?