Linus Torvalds has backed the idea of possibly removing Intel 486 (i486) processor support from the Linux kernel.
After the Linux kernel dropped i386 support a decade ago, i486 has been the minimum x86 processor support for the mainline Linux kernel. This latest attempt to kill off i486 support ultimately arose from Linus Torvalds himself with expressing the idea of possible requiring x86 32-bit CPUs with “cmpxchg8b” support, which would mean Pentium CPUs and later.
I think that would be a fair call. It’s highly unlikely any modern additions to the Linux kernel are usable on a 486 anyway, so existing kernels which still have support for this ancient processor should suffice. On top of that, there’s no doubt in my mind that at least someone or some group of people will step up to maintain a special 486 branch if there is indeed any residual need for it.
Agreed. There would be a very narrow need for modern Linux support on 486 hardware.
It has to be a 30+ year old industrial system that needs to run new software, but at the same time could not upgrade the hardware for one reason or another. Or it has to be networked, and needs security updates, but cannot be protected by an external firewall.
Anyway, even the low power chips have moved on to at least the Pentium architecture:
https://en.wikipedia.org/wiki/Intel_Quark
You can always patch the support back in if you need it, indeed. And now I wonder, did anyone patch support for removed architectures (i386 or avr32) into a newer kernel? How much effort would such take? Looking at this case, the support depends on an instruction, thus only a part written in assembly is affected, right?
I’d imagine patching support of variants of a still supported architecture would be some assembler parts. Patching support for a whole removed architecture such as avr32 would take much more effort, as those effect portions of the kernel written in C as well.
Andre,
I agree the impact should be relatively minor if that’s all it were. However it will depend on how much devs actually end up changing once pentium becomes the new required minimum. They could start requiring other pentium CPU features.
Most 486 CPUs don’t support a CPUID instruction (which is actually used quite a bit).
Pentium introduced the intergrated interrupt controller.
https://en.wikipedia.org/wiki/Advanced_Programmable_Interrupt_Controller
Most 486 CPUs lack registers like CR4 and associated features.
Pentium introduced MMX.
I’m not suggesting linux needs all of these, but just wanted to point out the ways that linux might start to diverge past 486.
If those features became mandatory, why not, but for “simple” CPU scheduling, Linus has set the 386 as the minimal standard to run Linux to begin with. What does ‘cmpxchg8b’ offers that is so specific to be required ?
Kochise,
As I see it, there’s nothing particularly critical about having cmpxchg8b, at the end of the day it’s just a performance optimization. In my code I often use cmpxchg for a single 32bit integer/pointer, which is the largest word size the 486 can handle anyways. Whether a 64bit version is useful/needed comes down to specific algorithms. But in any case it can be emulated with more albeit slower instructions combinations, so I don’t think it’s a real deal breaker.
However the same might not be true of other features. Who’s to say whether linux will bother refactoring other low level code after pentium becomes a minimum requirement, but conceivably code based on the CR4 registers and APIC could involve more structural changes that would require more technical expertise to backport than finding and replacing trivial cmpxchg8b instructions.
Alfman,
It has been a while since I looked at the Linux kernel code. However, there is more than just instructions to the hardware platform.
Linux has very small amount of direct assembly code:
https://github.com/torvalds/linux/search?l=assembly
And there would be some more scattered inside C as instincts or inline assembly.
Those parts can probably be back-ported easily.
There is also memory management and other assumptions about the platform:
https://github.com/torvalds/linux/blob/master/mm/hugetlb.c
Like floating point support:
https://github.com/torvalds/linux/blob/64a925c9271ec50714b9cea6a9980421ca65f835/arch/x86/math-emu/fpu_trig.c
Or hardware power management:
https://github.com/torvalds/linux/blob/4dc12f37a8e98e1dca5521c14625c869537b50b6/drivers/platform/x86/intel/pmc/core.c
Once those features are dropped, it might require additional effort to keep all these patches in sync.
Just to be complete, 121 different files refer to 486 inside Linux codebase:
https://github.com/torvalds/linux/search?q=486
sukru,
I agree. You could replace these with a function call or possibly even an invalid instruction trap to use the opcode as is.
Yes, I considered that, however even on newer processors I don’t think linux intends to require huge pages (it will continue to be optional) so 486 should continue to be viable in this respect.
It’s interesting to look at the specific caveats in that file, like precision and certain edge conditions. But I doubt those running linux on a 486 care that much about 128bit precision for PI or trigonometric functions of infinity. But to the extent these were important, I don’t think it’s a big deal to patch these back in.
Do you see anything specific to 486? I believe that early power management was handled by the BIOS and system management mode. I started using linux on newer processors than this, and even then I recall power management usually did not work. The computer would be on and that was that. It wouldn’t surprise me that OS power management simply never worked with linux on computers of that era. So maybe there’s no support to be deprecated. I’m curious if you have more information though.
That’s what I was thinking, but it might not be that bad either. It depends on how much they decide to refactor. In any case it won’t affect me, the oldest hardware I have is much newer than this.
Well, it is not just replacing ASM instructions but also ensuring that you have a compiler that supports both your target architecture that also meets the minimum requirements for the kernel you want to run.
The kernel build system and other minimum dependencies also have to be taken into account.
https://www.kernel.org/doc/html/latest/process/changes.html
Kernel 6.1 is about to add Rust support which means fairly up to date LLVM support.
Within the kernel code itself, there can be subtle assumptions about the minimum hardware present on the systems it supports. I do not have a detailed list of what might exist in Pentiums that does not in an i486 but it is not just ASM code that takes advantage of those features. When Linus pitched removing i486 support he referenced simplifications in the SMP code for example ( Symmetric Multiprocessing ). He also referenced PAE ( Physical Address Extension ) which I do not think even the original Pentium supports.
Other resources could become limiting factors as well. Gentoo still supports i486 but you need at least 48 MB of RAM which is probably not happening on most i486 systems.
Anyone still using 486 machines (usually in some embedded system) will most likely better served by using one of the (many) LTS kernel releases. Last of which (5.4/5.10) will be supported up until 2025/2026 respectively.
Yes, somebody will step up to support it. There is still a maintained version of Linux for i386 ( last updated just a few days ago ).
https://github.com/marmolak/gray386linux
The same developer is already ahead of the curve with an i486 distribution that has already been upgraded to Linux kernel 6.0 and GCC 12.2.
https://github.com/marmolak/gray486linux
There are a few mainstream distros that still maintain 32 bit versions. I bet some of those will work on i486 though I am not sure which ones and I doubt many of them would go out of their way to maintain this compatibility if the kernel dropped support.
Gray Linux seems in it for the long haul though.
tanishaj,
My linux distro still supports 32bit. I do have some 32bit NAS machines. If mainline linux were to drop the entire ia32 architecture, I don’t have the resources to maintain it independently. It’s hassle enough just to maintain out of tree drivers for supported architectures, haha.