Linux kernel developers are renewing efforts to retire the x32 application binary interface (ABI), a little-used compatibility feature that attempted to combine the advantages of 64-bit processors with the smaller memory footprint of 32-bit applications. A revised patch series submitted on October 8, 2026, proposes the first steps toward disabling the interface, potentially ending support for an architecture experiment introduced more than 14 years ago.

The latest proposal comes from Sebastian Andrzej Siewior, a Linux kernel developer at Linutronix who has been working on the removal effort throughout 2026. Rather than immediately deleting every component associated with x32, the proposed approach would first prevent the feature from being enabled through normal kernel configuration. This would give remaining users and distribution maintainers an opportunity to respond before the underlying implementation is removed.

The effort reflects a broader challenge in Linux development: maintaining compatibility with older or rarely used technologies while keeping the kernel manageable, secure, and efficient. Although x32 offered theoretical performance and memory advantages, it never achieved widespread adoption. With conventional x86_64 software dominating modern Linux systems, developers are increasingly questioning whether the additional maintenance burden remains justified.

Understanding the Linux x32 ABI

The x32 ABI was introduced with Linux kernel 3.4 in 2012 as an alternative to conventional 32-bit and 64-bit application environments. Its goal was to provide applications with access to the architectural improvements of x86_64 processors while retaining smaller data types and pointers associated with 32-bit software.

Traditional 32-bit x86 applications use the i386 ABI, which operates with a more limited register set and 32-bit execution conventions. Standard x86_64 applications, meanwhile, benefit from additional general-purpose registers, wider registers, and modern calling conventions, but they normally use 64-bit pointers. Those larger pointers can increase memory consumption in applications that maintain large numbers of pointer-heavy data structures.

The x32 ABI attempted to offer a compromise. Applications would execute using the x86_64 instruction set and its larger register file while retaining 32-bit integers, long values, and pointers. This programming model is commonly described as ILP32, meaning that integers, long integers, and pointers are all 32 bits wide.

The distinction can be illustrated by comparing the expected sizes of common C data types:

Data type	i386	x86_64	x32
int	32 bits	32 bits	32 bits
long	32 bits	64 bits	32 bits
Pointer	32 bits	64 bits	32 bits
CPU execution mode	32-bit	64-bit	64-bit

For workloads that did not require a large virtual address space, this approach could theoretically reduce memory consumption without sacrificing the instruction-set capabilities of modern x86 processors. The expectation was that some applications would benefit from smaller memory structures and improved cache efficiency, particularly when working with large collections of pointers.

Why x32 Never Became a Mainstream Linux Architecture

Despite its technical appeal, x32 arrived at a time when the Linux ecosystem had already moved decisively toward conventional 64-bit software. By 2012, x86_64 processors were widely available, major Linux distributions supported 64-bit installations, and most application developers were increasingly targeting the standard x86_64 ABI.

The potential memory savings offered by x32 were not enough to overcome the practical costs of maintaining another application environment. Software projects needed compatible compiler and library support, distributions needed additional packages and testing infrastructure, and developers had to account for differences between x32 and conventional 32-bit or 64-bit interfaces.

The performance advantages were also workload-dependent. Applications that allocated large amounts of pointer-heavy data could potentially benefit from smaller pointers, but software with different memory-access patterns might see little improvement. Meanwhile, ordinary x86_64 systems continued gaining memory capacity and performance, reducing the incentive to adopt a specialized ABI.

As a result, x32 remained a niche technology rather than becoming a widely supported Linux platform. Although it found some users and distribution-level support, it never developed the broad ecosystem needed to justify the complexity of maintaining it indefinitely.

Updated Patches Target the X86_X32_ABI Configuration Option

The latest removal proposal focuses on the kernel configuration symbol CONFIG_X86_X32_ABI, which controls whether the kernel includes support for executing x32 applications. The proposed change would place that capability behind the kernel's BROKEN configuration condition, effectively preventing it from being selected through normal kernel configuration tools.

A simplified representation of the intended restriction looks like this:

config X86_X32_ABI
    bool "x32 ABI for 64-bit mode"
    depends on X86_64
    depends on BROKEN

This example illustrates the proposed configuration restriction rather than reproducing the complete kernel patch. The BROKEN dependency is commonly used in kernel development to make functionality unavailable through normal configuration when developers consider it unsuitable for regular use.

The staged approach matters because it separates disabling the feature from removing its implementation. Kernel maintainers could first prevent new builds from enabling x32 while retaining the associated code temporarily. That would create an opportunity to identify any overlooked users before deleting the implementation in a subsequent development cycle.

Earlier versions of the removal proposal explored eliminating the configuration symbol directly. The updated approach is more conservative, reflecting the importance of managing compatibility changes carefully even when a feature has limited adoption.

Why Removing x32 Could Simplify the Linux Kernel

Maintaining an additional ABI involves more than preserving a single configuration option. An application binary interface defines how programs communicate with the operating system, including system-call conventions, data structure layouts, register usage, and the interpretation of values passed between user space and kernel space.

The x32 ABI creates complications because it combines characteristics of 32-bit and 64-bit environments. Some interfaces resemble conventional x86_64 behavior, while others require special handling for 32-bit pointers, integer sizes, or structure alignment. This can require developers to maintain an additional compatibility path alongside the ordinary 32-bit and 64-bit implementations.

Those special cases can extend into filesystems, device drivers, system-call handling, and compatibility code. Every additional path must be reviewed when interfaces change, tested when regressions appear, and considered when security vulnerabilities are discovered. Even if relatively few users execute x32 applications, the code supporting them remains part of the kernel's maintenance responsibilities.

Removing x32 would allow developers to eliminate some of these exceptional cases and reduce the number of execution environments that must be considered when modifying kernel interfaces. The immediate reduction in source code may not transform kernel performance, but simplifying compatibility logic can make future development and maintenance easier.

Security Concerns Have Accelerated the Discussion

Security is another important factor behind the renewed removal effort. Every supported ABI exposes a collection of kernel interfaces that must be maintained and protected, and x32 introduces additional compatibility behavior that is rarely exercised by ordinary users.

When a kernel supports multiple system-call conventions, developers must account for differences in argument handling, structure alignment, and data conversion. Bugs in these compatibility paths can create vulnerabilities even when the corresponding native 64-bit implementation behaves correctly. Maintaining an interface that receives relatively little real-world testing can therefore increase the amount of code that security researchers and maintainers need to evaluate.

Debian previously introduced a change that disables x32 execution by default, requiring users to explicitly enable the functionality through a kernel boot parameter. Fedora has also generally avoided enabling x32 support in its kernel configurations. These decisions demonstrate that major distributions have already treated the interface as unnecessary for typical installations.

The current removal proposal would extend that direction upstream. Rather than leaving individual distributions to decide whether to expose the interface, the Linux kernel itself could eventually stop providing x32 support altogether.

x32 Removal Does Not Mean Linux Is Dropping 32-Bit Applications

One important distinction is that the proposed change concerns the x32 ABI, not conventional 32-bit x86 compatibility. The two interfaces are different, despite their similar names and their shared use of 32-bit data types.

The standard i386 ABI allows traditional 32-bit x86 applications to run on compatible Linux systems. This capability remains relevant for legacy software, certain development environments, and compatibility technologies that execute older applications. The x32 ABI, by contrast, runs applications using the x86_64 instruction set while retaining an ILP32 data model.

On a conventional 64-bit Linux kernel, support for traditional 32-bit applications is associated with configuration options such as CONFIG_IA32_EMULATION. The x32 interface uses its own configuration symbol, CONFIG_X86_X32_ABI, and its own system-call conventions.

Consequently, removing x32 would not automatically prevent ordinary 32-bit x86 applications from running on a kernel that continues to provide IA32 compatibility. It would specifically affect binaries built for the x32 environment.

This distinction is especially important for Linux gaming and compatibility software. Users should not interpret the proposal as an announcement that the kernel is eliminating all support for 32-bit applications.

The x32 System-Call Numbering Problem

One particularly complicated aspect of removing x32 involves Linux system-call numbers. System calls provide the interface through which user-space programs request operations from the kernel, such as opening files, allocating memory, creating processes, or communicating with devices.

The x32 ABI uses a special convention to distinguish its system calls from conventional x86_64 operations. In particular, it uses the __X32_SYSCALL_BIT flag, represented by 0x40000000, together with system-call numbering conventions that include an x32-specific range beginning at 512.

These conventions create compatibility complications even after x32 support is removed. Kernel developers have discussed whether the numbers historically associated with x32 could be reused for other system calls, but doing so could introduce ambiguity when interacting with older kernels or software that interprets those numbers differently.

The concern is that earlier kernels did not always separate x32 system-call handling in the same way as newer implementations. Reassigning previously reserved numbers could therefore create unexpected compatibility problems. Developers have consequently argued that the x32-specific numbering range should remain reserved rather than being recycled.

This means eliminating the ABI will not necessarily free every resource associated with it. Some historical interface decisions may need to remain documented indefinitely to preserve predictable behavior across kernel versions.

Linux Developers Have Debated the Removal Throughout 2026

The October patch series is the latest development in a discussion that has been underway for several months. Earlier proposals appeared during the spring and summer of 2026, with developers examining how much x32 code could be removed and whether any meaningful user base remained.

Several prominent kernel developers have expressed support for retiring the interface, arguing that its maintenance costs outweigh its practical value. The discussion has also highlighted how x32 differs from other ILP32 environments, including the n32 ABI used on MIPS systems. Although both involve smaller data types on processors with wider registers, their kernel compatibility requirements are not identical.

Not everyone involved in the discussion has dismissed x32 as completely unused. Developers have pointed out that PLD Linux has maintained x32 support for years, including modifications to RPM packaging infrastructure. That example demonstrates that the ABI has supported real deployments, even if those deployments represent a small fraction of the wider Linux ecosystem.

The existence of these users is one reason a staged removal process makes sense. It allows developers to assess compatibility concerns and provide advance warning rather than abruptly deleting an interface that may still matter to specialized installations.

The Last 2026 LTS Kernel Could Mark the Transition

The current proposal also considers the timing of the final Linux long-term support kernel selected for 2026. The idea is to retain the x32 implementation through that release before completing its removal afterward, giving users a final supported kernel branch that still contains the functionality.

This timing remains dependent on kernel development decisions and the eventual selection of the year's LTS release. Linux kernel version numbers alone do not determine which release receives long-term support, and the removal patches still need to be reviewed and accepted before their effects become part of an official kernel release.

The staged approach would also provide distributions and specialized users with additional time to plan. Organizations relying on x32 binaries could remain on an appropriate supported kernel while evaluating alternatives, although they would eventually need to consider the long-term consequences of maintaining software that depends on a retired interface.

For most Linux users, the transition would likely be invisible because their systems already use conventional x86_64 binaries and do not enable x32 support.

How to Check Whether Your Kernel Supports x32

Most Linux users will never need to investigate x32 compatibility because their applications are built for the standard x86_64 ABI. However, administrators maintaining older or specialized systems may want to determine whether their kernel was compiled with the interface enabled.

On systems that expose the running kernel's configuration through /proc/config.gz, the following command can identify the relevant setting:

zcat /proc/config.gz | grep CONFIG_X86_X32_ABI

Some distributions store the kernel configuration under /boot instead. In that case, users can try:

grep CONFIG_X86_X32_ABI /boot/config-$(uname -r)

If the result is CONFIG_X86_X32_ABI=y, the kernel was built with x32 support. If the option is unset, the kernel does not include the corresponding compatibility feature. These checks reveal the kernel's build configuration, but they do not necessarily establish whether x32 execution is permitted at runtime, since additional distribution-specific restrictions may apply.

Administrators can also inspect executable files using the file command:

file /usr/bin/bash

A conventional 64-bit Linux executable will normally be identified as an ELF 64-bit x86-64 binary. An x32 executable uses a different ELF class and ABI configuration, allowing tools to distinguish it from ordinary 64-bit software. For organizations maintaining custom x32 applications, checking the actual binaries is more useful than assuming that every program running on an x86_64 processor uses the standard 64-bit ABI.

What Happens to Existing x32 Applications?

If the Linux kernel eventually removes x32 support, applications compiled specifically for that ABI will no longer execute natively on kernels without the necessary compatibility implementation. This does not mean their source code necessarily becomes unusable, but affected software would need to be rebuilt for another supported ABI or run in an environment that retains x32 compatibility.

For applications with available source code, rebuilding for conventional x86_64 may be the most straightforward long-term option. The transition can still require work, particularly if the application relies on assumptions about pointer sizes, data structure layouts, or external libraries built specifically for x32.

Software distributed only as x32 binaries presents a more complicated problem. Organizations may need to preserve a compatible kernel environment or replace the software with an alternative. A container alone would not solve the problem if its host kernel no longer supports x32, because containers share the host's kernel and cannot independently restore a removed system-call ABI.

A virtual machine running an older, supported kernel could provide a compatibility environment for specialized workloads. However, maintaining older kernel versions also introduces security and operational considerations, so this approach should be treated as a temporary compatibility strategy rather than a permanent substitute for updating affected software.

The Broader Push to Reduce Legacy Kernel Complexity

The proposed retirement of x32 illustrates how Linux development continues balancing compatibility against long-term maintainability. The kernel has historically preserved application interfaces for extended periods, allowing software built years earlier to continue functioning on newer systems. That commitment is one of Linux's strengths, particularly in enterprise and infrastructure environments where applications may remain deployed for many years.

However, preserving every interface indefinitely also has costs. Older features require testing, security review, documentation, and occasional changes whenever surrounding kernel infrastructure evolves. If a feature serves very few users, maintaining it can consume development resources that might otherwise improve more widely used functionality.

The x32 ABI is a particularly interesting example because it was introduced to solve a genuine technical problem rather than simply preserve obsolete hardware. Its design offered potential memory-efficiency advantages, but the surrounding ecosystem never adopted it broadly enough to make those advantages compelling for most users.

Retiring x32 would therefore represent a decision about the practical value of maintaining a specialized execution environment. The kernel would continue supporting mainstream x86_64 software and conventional 32-bit compatibility where configured, while eliminating an additional ABI that has required disproportionate maintenance relative to its adoption.

Conclusion

Linux kernel developers are moving closer to retiring the x32 ABI, with updated patches submitted on October 8, 2026, proposing a staged approach to disabling the rarely used interface. The latest proposal would first make CONFIG_X86_X32_ABI unavailable through normal kernel configuration before removing the remaining implementation after the final 2026 LTS kernel is selected.

The decision reflects more than a lack of popularity. Although x32 originally promised smaller memory footprints while retaining the architectural advantages of x86_64 processors, its specialized data layouts and system-call conventions introduced additional compatibility code that developers must continue maintaining and securing.

For ordinary Linux users, the proposed change should have little practical impact. Standard x86_64 applications and conventional i386 compatibility are separate from the x32 ABI, and removing the latter does not automatically eliminate support for traditional 32-bit software.

Specialized users and distributions that still depend on x32 will need to follow the kernel mailing list discussions and prepare for a possible transition. The patches have not yet established a finalized removal schedule, but the renewed effort makes the project's direction increasingly clear: Linux developers want to simplify the kernel by retiring an experimental ABI that never achieved the adoption originally envisioned for it.