Patch to end i486 support hits Linux kernel merge queue

After a year of patchwork, maintainers look ready to start retiring 486-class CPUs It's taken nearly a full version number to get the pieces in order, but the long-awaited end of 486 chip support in the Linux kernel appears to be nigh with Linux 7.1's release later this year. …

Patch to end i486 support hits Linux kernel merge queue
Patch to end i486 support hits Linux kernel merge queue Photo: The Register

After a year of patchwork, maintainers look ready to start retiring 486-class CPUs
It's taken nearly a full version number to get the pieces in order, but the long-awaited end of 486 chip support in the Linux kernel appears to be nigh with Linux 7.1's release later this year.

Slated for the 7.1 merge window is a patch that veteran Linux kernel contributor Ingo Molnar queued up at the end of March, but which went widely unnoticed until over the weekend.

If merged, the patch would begin phasing out support for 80486-generation chips by removing the M486, M486SX, and MELAN configuration options from Kconfig, effectively preventing new upstream kernels from being configured specifically for 486-class systems.

The change has been a long time coming, and would begin the process of removing processor architecture support from the kernel for the first time since 2012 , when support for 80386 processors was removed.

As he noted in 2022 when first contemplating removal of 80486 chips from the kernel, Linux maestro Linus Torvalds was similarly unsentimental when killing the 386.

"I *really* don't think i486 class hardware is relevant any more," Torvalds said in 2022, noting that while some people may still operate 486 systems they aren't relevant from a kernel development standpoint.

"At some point, people have them as museum pieces.

They might as well run museum kernels."
In other words, if you want to run an old piece of hardware, you're just gonna have to rely on an old version of the Linux kernel going forward from 7.1, finally.

That's not to say the kernel maintainers haven't been working on the 486 support purge for some time – Molnar first proposed dropping 486 support in April 2025.

Molnar noted a discussion he had with Torvalds in the patch notes, which were published in late April 2025, where he reiterated his feeling that it was time to ditch 486 support because it was wasting developers' time.

Molnar similarly justified the elimination of 486 support in the notes.

"We have various complicated hardware emulation facilities on x86-32 to support ancient 32-bit CPUs that very very few people are using with modern kernels," Molnar explained.

"This compatibility glue is sometimes even causing problems that people spend time to resolve, which time could be spent on other things."
To get around that wasted time, Molnar originally proposed eliminating 486 support by requiring the next kernel version to require chips to support Time Stamp Counter and the CMPXCHG8B instruction, which aren't present in 80486-family chips and some 586 derivatives.

It's not clear what happened in the just shy of a year since this proposal was made, but the kernel.org discussion chain that began with those recommendations has been ongoing for a year, with Molnar making multiple rounds of changes to his proposal since then.

As of this latest merge request, it appears simply cutting off the configuration options for 486-family chips has been chosen as the way forward.

With the final release of the Linux kernel 7.0 due sometime in the next few months, 7.1 can be expected sometime in the middle of this year, though whether this 486-killing patch proposal finally makes the cut remains to be seen.

Either way, Molnar noted in his request, there's no recent kernel package that supports 486 chips, so "actual users should not be impacted" either way.

"Legacy users can keep using older kernels," Molnar added.

®

Source: This article was originally published by The Register

Read Full Original Article →

Share this article

Comments (0)

No comments yet. Be the first to comment!

Leave a Comment

Maximum 2000 characters