Linux is finally dropping i486 support

Linux kernel maintainers may finally be ready to turn off support for 80486-class CPUs. The latest patch queued by Ingo Molnar would remove the M486, M486SX, and MELAN config options, which means new upstream kernels would no longer be buildable for 486-only systems.

That matters less for people running real 486 hardware than it does for the people maintaining x86-32 code paths. The proposal has been circulating since April 2025, and the timing points at Linux kernel 7.1 later this year, after the 7.0 release lands in the next few months.

Why this patch is getting attention now

The kernel has been carrying 486 support for a very long time, but the practical user base has shrunk to almost nothing. According to the patch notes, the change would stop upstream configuration for 486-class systems rather than ripping out every last line of compatibility code in one go.

That distinction matters. Linux kernel development often removes support in stages, because outright deletion can break build assumptions, testing setups, and old distribution tooling. Here, the first step is to stop promising support to new builds.

There is also a simple maintenance argument. Every ancient CPU feature that stays in the tree adds code paths, review work, and debugging overhead. For a project this large, even a small amount of dead weight can create friction for people working on current hardware.

• Patch author: Ingo Molnar
• Target release window: Linux 7.1
• Config options affected: M486, M486SX, MELAN
• Earlier architecture drop: 80386 support was removed in 2012
• Proposal first raised: April 2025

Linus Torvalds already made the case

This is not a surprise decision. Linus Torvalds has been blunt about 486-era systems for years, and his view is that they belong in history, not in the active kernel tree. He said in 2022 that he did not think i486-class hardware was relevant anymore.

“I *really* don't think i486 class hardware is relevant any more,” Torvalds said in 2022, adding that old machines might as well run museum kernels.

That quote is the key to understanding where the project is headed. The Linux kernel is not a preservation project for every CPU ever made. It is a living codebase, and maintainers keep asking whether a feature still helps real users or just keeps old assumptions alive.

Molnar made the same point in his patch notes. He argued that the compatibility glue for ancient 32-bit CPUs eats developer time and can even create bugs that people then have to chase down. In kernel work, that kind of hidden cost adds up fast.

What changes technically

The latest version of the proposal drops the idea of requiring newer instructions like Time Stamp Counter and CMPXCHG8B as the gatekeeper. Instead, it takes a simpler route: remove the ability to configure the kernel for 486-family chips through those Kconfig options.

That is a cleaner administrative cut, and it reduces the chance of half-supported configurations lingering in the tree. It also aligns with the direction kernel maintainers have been moving in for years, where old CPU families slowly lose first-class status before any deeper cleanup happens.

The interesting part is that this does not strand current users overnight. Molnar noted that no recent kernel package supports 486 chips anyway, so actual users should not notice a sudden break. If someone is still running a 486, the path forward is older kernel releases, not current upstream builds.

• Old requirement idea: TSC and CMPXCHG8B support
• Current proposal: remove 486-specific Kconfig entries
• Compatibility impact: upstream kernels stop being configurable for 486-only CPUs
• User impact: minimal, because recent kernels already ignore 486 hardware
• Historical comparison: 80386 support left the tree in 2012

What this says about Linux in 2026

This patch is a reminder that kernel development is partly about subtraction. The project gets faster to maintain when it stops carrying code for machines that have not mattered in years. That is true for 486 support, and it will be true for other old assumptions too.

For distro maintainers, the practical takeaway is simple: keep an eye on upstream architecture policy if you ship long-lived enterprise branches or build custom kernels for embedded gear. For hobbyists, the message is even simpler: if your machine is old enough to vote, it may already belong on an archival kernel.

If the patch lands in Linux 7.1, the next question is not whether 486 support disappears, but how long the rest of x86-32 compatibility stays untouched. My bet: this is one more step toward a smaller, easier-to-maintain kernel, and the next cleanup proposal will not take nearly as long to arrive.

For more kernel context, see our coverage of how Linux maintainers handle legacy CPU support and why old hardware keeps showing up in open source debates.