The Linux kernel stands at another crossroads in its long effort to prune legacy code. Developers have begun the formal process of removing support for the x32 ABI, an interface introduced more than a decade ago with high hopes but scant real-world uptake. If the current proposal holds, 2026 will mark the end of this experimental path for x86-64 systems.
Sebastian Andrzej Siewior of Linutronix submitted a patch last week that disables the CONFIG_X86_X32 option outright. He laid out the case plainly. “The x32 ABI was introduced in v3.4 to leverage the additional registers which were available on x86_64 but not on i386 while keeping the smaller 32bit pointers,” he wrote. “This did not take off.”
Memory demands in modern workloads rarely stay under 4GB. Performance gains from the hybrid approach never proved decisive enough to shift large applications or distributions toward exclusive x32 use. Debian added a boot-time enablement requirement out of security concerns over expanded attack surface. Fedora keeps the feature turned off. Real usage, Siewior concluded, is practically nonexistent. Phoronix first reported the proposal.
The patch starts small. It removes the Kconfig symbol so no one can enable x32 anymore. Should no significant objections surface in the next six months, the bulk of the supporting code would follow in August after the summer break. No one has pushed back yet. One reviewer offered only a minor note against recycling the reserved system call numbers.
And the numbers tell their own story. The last native x86-64 syscall sits at 471. x32 calls begin at 512. Forty slots sit idle in between. Dropping x32 would free those for future expansion without compatibility headaches.
x32 arrived with Linux 3.4 in 2012. The idea had circulated earlier. Donald Knuth himself expressed interest around 2008. H. Peter Anvin and others formalized the concept in 2011. The goal was straightforward. Give programs access to the full 64-bit register set and faster instructions available on x86-64 chips while limiting pointers to 32 bits. Smaller pointers meant tighter data structures, better cache behavior, and lower memory overhead.
Benchmarks at the time looked promising. Some integer workloads showed 5 to 8 percent gains. Certain cache-sensitive applications improved even more. Yet the 4GB address space limit proved a hard ceiling for many server and desktop tasks. Floating-point heavy code saw little benefit. Rebuilding entire toolchains and libraries added friction. Few distributions ever shipped x32 as a first-class option. Wikipedia notes support in Debian, Gentoo, Yocto and a handful of others, but always as a niche port.
By 2018 the conversation had already turned toward deprecation. Linus Torvalds signaled support for removal. Maintenance costs for minimal returns no longer made sense. Discussions on the kernel mailing list highlighted the same adoption shortfall now cited by Siewior. Nothing changed in the intervening years to reverse that verdict.
This move fits a larger pattern. The kernel continues to shed 32-bit support where practical. Arnd Bergmann outlined the broader picture in a September 2025 talk covered by LWN.net. He declared 32-bit systems obsolete for any new product. Existing hardware and software would receive continued care, but the future belongs to 64-bit architectures. High-memory support for more than 4GB on 32-bit kernels could vanish around 2027. Nommu variants might follow in 2028. The year-2038 problem adds further pressure. No 32-bit desktop environment is expected to survive it.
x32 sits in a strange middle ground. It is not the classic i386 ABI used for legacy 32-bit binaries. Those remain untouched for now. x32 requires recompilation. It offers 64-bit registers and system call conventions but caps virtual address space at 4GB. That compromise never found a large enough constituency.
Some enthusiasts still compile specialized workloads with x32. A few embedded or memory-constrained setups might notice the difference. Yet the broader industry moved on. Cloud instances favor full 64-bit. Modern applications assume generous address spaces. RAM prices dropped. Cache hierarchies grew sophisticated enough that pointer size became less decisive.
Removal will simplify the kernel. Fewer architecture-specific paths. Cleaner syscall tables. Less testing burden. Distributors can drop associated glibc and compiler packages. Toolchain maintainers gain breathing room.
But. The process demands care. Any remaining users must speak up soon. The six-month window gives them time. After that, code starts disappearing. And once gone, it stays gone.
So the Linux kernel edges forward. It sheds another experiment that once seemed clever. x32 joined the kernel with promise. It leaves with quiet acceptance that the bet did not pay off. The de facto standard won. Full x86-64 rules the day.
Developers expect the patch series to advance without drama. By this time next year the option may already be unavailable in mainline kernels. 2026 will close the book on x32. The code that supported it will shrink to footnotes in git history.
WebProNews is an iEntry Publication