Linux Kernel Developers Discuss Dropping A Bunch Of Old CPUs

[jabl]

I don't mind any of the gone for latest 5.10+ LTS.
I'm a bit surprised about the C6x though.
Maybe that support was always shitty so it has to go anyway?

From the linked email message:

* c6x: Added in 2011, this has seen very few updates since, but Mark still Acks patches when they come. Like most other DSP platforms, the model of running Linux on a DSP appears to have been obsoleted by using Linux on ARM with on-chip DSP cores running bare-metal code.

[Neraxa]

Is there any benefit to removing these other than less lines of code in the kernel, and less to maintain?
Example maybe removing 486 will that somehow maybe be possible to improve the kernel in some way to make it cleaner, faster, more stable or more secure?

All architecture dependent stuff should be modularized and compartmentalized from the architecture independent parts of the code base, so the answer is no. If you use a modern chip this should have absolutely no impact on you, there would be no improvement in clean, readability, stability, or security by removing this code, provided the kernel is properly designed, which it is. So removing it is mainly an obsessive compulsive thing because someone doesnt like seeing the subdirectory for the architecture in the tree.

[Neraxa]

Removing support for old x86 cpu's can make the code slightly cleaner as you can unconditionally assume that newer features are present. 386 support, which was removed in 2012, thus bumping the minimum to 486, was kind of nice as there was some ugly 386-specific page table handling code and atomics code that they could get rid of. Getting rid of 486 doesn't seem to have such a big benefit, per https://en.wikipedia.org/wiki/X86_instruction_listings there's CPUID, RDTSC, CMPXCHG8B, {RD,WR}MSR.

It really should be slight. If there are subarchitectures which share common code, then you put the common code in some files and then you put the subarch files in other files, you then use a compile time preproc argument to indicate which subarch files to use when building for a subarch. Either the subarch files can pull in from common files, or the common files can pull in blocks of code from subarch files, using placeholders for where the blocks of code should go, being filled in by files selected at compile time.

[Tuxee]

Is there any benefit to removing these other than less lines of code in the kernel, and less to maintain?

Isn't that sufficient already?

[uid313]

Isn't that sufficient already?

Yes, but I would also be interested if it brought any additional benefits. Like some weird quirks that are no longer needed.

[robclark]

Looking at these stats, it seems to suggest that the vast majority is amd64 and i686.

Almost everything else including aarch64 (1.1%), armv7l (0.3%), and others (0.1%) can be dropped

Even i686 is only 3% but if that is going to go, then ARM is going to have to go first.

(Yes these stats are likely unreliable and have very low numbers of results but... to be fair, probably still show valid trends).

what stats?

(I'd be extremely surprised if there are more amd64 things than aarch64 things running a linux kernel.. but maybe that isn't what the stats you refer to are..)

[kpedersen]

what stats?

(I'd be extremely surprised if there are more amd64 things than aarch64 things running a linux kernel.. but maybe that isn't what the stats you refer to are..)

Yeah, the dimwit forgot to add the link to the specific stats to their post : https://linux-hardware.org/index.php?view=os_arch

aarch64 is actually fairly rare for Linux. You have Raspberry Pi, a few other hobbiest SoC and very few servers that only a small number of companies can seem to get hold of. Yes, you could include Android in all that but that is like saying that Linux has a higher market share than Windows. It is a technicality that is fairly meaningless.

These same stats also suggest that Wayland is much less popular than X11: https://linux-hardware.org/index.php...display_server
So even though small numbers, they look about right.

[robclark]

Yeah, the dimwit forgot to add the link to the specific stats to their post : https://linux-hardware.org/index.php?view=os_arch

aarch64 is actually fairly rare for Linux. You have Raspberry Pi, a few other hobbiest SoC and very few servers that only a small number of companies can seem to get hold of. Yes, you could include Android in all that but that is like saying that Linux has a higher market share than Windows. It is a technicality that is fairly meaningless.

Ahh, ok, so more of a "generic distro" stat. That sounds a bit more believable. (I wonder of aarch64 cloud servers end up getting counted.. although at this point I'd suspect they are still somewhat fewer than amd64.)

But as far as considering linux kernel users, and which archs/boards should remain, I think it is fair to count all things that use the linux kernel, so including android/routers/IoT things, etc. And yes, the linux *kernel* does have a higher market share than windows.

[nokipaike]

I don't know, crippling these cpus seems like a hidden way to prevent the proliferation of free cpu reborn (and that can evolve reimplemented on fpga) no longer covered by patents ...

[Adarion]

Looking at these stats...

https://linux-hardware.org/index.php?view=os_arch

Don't be fooled by some platforms and their "hardware surverys". They're not really representative. (Same goes for steam)
What do these platforms cover? User entries where users actively enter data? Nah, not really good.
Who covers all the many applications in industry, embedded and whatnot? Or just users never "seen" by this surverys.

I'd be careful with numbers. There may be several obscure systems, for sure, but even i486 isn't that obscure.