I'm seriously considering sending a patch to remove x32 support fromupstream Linux. Here are some problems with it:

1. It's not entirely clear that it has users. As far as I know, it'ssupported on Gentoo and Debian, and the Debian popcon graph for x32has been falling off dramatically. I don't think that any enterprisedistro has ever supported x32.

2. The way that system calls work is very strange. Most syscalls onx32 enter through their *native* (i.e. not COMPAT_SYSCALL_DEFINE)entry point, and this is intentional. For example, adjtimex() usesthe native entry, not the compat entry, because x32's struct timexmatches the x86_64 layout. But a handful of syscalls have separateentry points -- these are the syscalls starting at 512. These enterthrough the COMPAT_SYSCALL_DEFINE entry points.

The x32 syscalls that are *not* in the 512 range violate all semblanceof kernel syscall convention. In the syscall handlers,in_compat_syscall() returns true, but the COMPAT_SYSCALL_DEFINE entryis not invoked. This is nutty and risks breaking things when peoplerefactor their syscall implementations. And no one tests thesethings. Similarly, if someone calls any of the syscalls below 512 butsets bit 31 in RAX, then the native entry will be called within_compat_set().

Conversely, if you call a syscall in the 512 range with bit 31*clear*, then the compat entry is set with in_compat_syscall()*clear*. This is also nutty.

Finally, the kernel has a weird distinction between CONFIG_X86_X32_ABIand and CONFIG_X86_X32, which I suspect results in incorrect builds ifthe host doesn't have an x32 toolchain installed.

I propose that we make CONFIG_X86_X32 depend on BROKEN for a releaseor two and then remove all the code if no one complains. If anyonewants to re-add it, IMO they're welcome to do so, but they need to doit in a way that is maintainable.