Conversation
Edited 19 days ago
After 25+ years of kernel development, I was finally forced to touch `mm/` and it was due to a nommu "issue":
https://lore.kernel.org/lkml/2026042334-acutely-unadorned-e05c@gregkh/

As @axboe said the other day, we aren't expecting a box of chocolates:

https://lore.kernel.org/r/2f2c91cb-f20e-44eb-8ba3-2d5b3d649642@kernel.dk

but these past weeks have made me feel like someone owes a few of us kernel developers a bunch of whisky at the very least...
3
9
31

@gregkh @axboe /me cries in epoll

1
0
1
@brauner @axboe You most certianly deserve a crate of whatever you want!
0
0
3

@gregkh I'll take a whisky over a box of chocolates anyway ;-)

1
0
0

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

1
2
1

@Aissen @gregkh @ljs @vbabka As any sane person should! Honestly, I'm hope this will be the silver lining to the slew of mostly garbage LLM bug reports - yank the old and untested code from the kernel, not just nommu.

2
0
1

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

1
3
2
@Aissen @axboe @gregkh @ljs @vbabka

bittersweet because people report bugs on features they don't use rather than fixing them and stepping up to help?
2
0
0

@hyeyoo @ljs @vbabka @gregkh @Aissen That's not bittersweet, that's just laziness. So much easier to run LLMs on code and report issues they often don't even understand, than it is to write a patch.These people don't care about the code, that's not why they are reporting the issues.

1
0
1

@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 🀣

1
1
1

@axboe @Aissen @gregkh @vbabka @david also I note that it doesn't seem that any of the imagined 'many' people who have interests in nommu lift a finger to maintain or test it.

So honestly on that argument alone it should go...

0
0
1

Harry (Hyeonggon) Yoo

Edited 19 days ago
@axboe @ljs @vbabka @gregkh @Aissen

it's really sad that people do that.
what do these people care then?
1
0
1

@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 :)

0
0
1
@axboe @ljs @vbabka @gregkh @Aissen

oh geez, that's not adding much value to the project :/
2
0
2

@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! ***

1
0
1
@ptesarik @axboe @ljs @vbabka @gregkh @Aissen

see my dominance signal, a claude subscription!
0
0
2

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

1
1
1

@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 :)

0
0
0

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

1
0
1

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

1
0
0

@axboe @hyeyoo @ljs @vbabka @gregkh That seems to be the plan on Jacub's side. https://github.com/linux-netdev/mod-orphan

Note: I'm not arguing against any removal, I'm not crazy enough to take on this type of maintenance. I was just commenting on the feeling.

2
0
0

@Aissen @hyeyoo @ljs @vbabka @gregkh This is the way. Nothing is free, have the people that want to use it pay the cost. The kernel people have enough to do without maintaining hardware they don't even have.

0
0
0

@Aissen @axboe @hyeyoo @vbabka @gregkh yeah I get it but it holds us back.

These things have VERY REAL impact on development and maintenance.

And when you've broken the nommu build by mistake for the 100th time you get tired of it...

0
0
0

@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?

1
0
0
@lesto Yes to the first, and for the second "you can always change the code to adapt over time". Make it work now, don't worry too much about the future as you don't know what it will hold.
0
0
0