Re: [PATCH] x86: Start removing X86_X32_ABI

["Arnd Bergmann" <arnd@arndb.de>]

On Tue, Jun 2, 2026, at 18:02, Maciej W. Rozycki wrote:
> On Mon, 1 Jun 2026, Arnd Bergmann wrote:
>
>> I think the main reason to remove x32 support is all the special
>> cases we have for it where it is different from normal 'compat'
>> syscall and ioctl handling, which leaks all the way into file
>> systems and device drivers (sound/core/pcm_compat.c,
>> fs/fuse/ioctl.c, fs/read_write, ...) as well as user space
>> trying to handle 64-bit time_t in a portable way.
>
>  FWIW it's no different from n32 MIPS ABI support, which we've had for 
> even longer and isn't going away anytime soon.  So there's undoubtedly 
> some x86-specific stuff there, but generic support for an ILP32 ABI is 
> there to stay both in the kernel and on the user side.

For the parts I'm interested in, it's a huge difference: MIPS o32
and n32 have essentially the same types and syscalls aside from the
few structures that describe the actual registers (pt_regs, sigcontext)
and the syscall numbers.

On x32, there are custom integer types (__kernel_ulong_t,
__kernel_old_time_t, __kernel_ipc_pid_t, __kernel_uid_t, ...)
and alignment rules that were intended to match the native x86-64
types for simplicity but end up doing the opposite by requiring
compat ioctl handling to be aware of the difference and implement
a third case when the x32 version is different from both the
i386 and the x86-64 one.

Even for the cases where x32 ends up using the same syscall
as x86-64 because of these type choices (e.g. gettimeofday),
this still needs a special case in the kernel because all other
compat architectures have a shared compat version.

      Arnd