Re: [PATCH] x86: Start removing X86_X32_ABI

[H. Peter Anvin]

On June 2, 2026 9:36:54 AM PDT, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>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

Yes, and that was the original intent for x86-x32 as well, with the idea being to let the various 32-bit APIs catch up at their own pace. 

Linus vetoed that.