On October 10, 2026 4:13:55 AM GMT+02:00, Tancred <[email protected]> wrote: > > >On 10/8/26 03:07, Sebastian Andrzej Siewior wrote: >> where certain workloads widely >> move to x32 and use it exclusively. In the meantime Debian introduced a >> patch to disable x32 by default (so it has to be enabled at boot time on >> the command line) because they are afraid of the increased attack >> surface. Fedora as far as I tell has X32 disabled (looking at 7.0-rc5 >> rpm in rawhide). >> >> Since there is practically no real use for x32 > >I only recently discovered x32 and built a Desktop (with all daemons and >utilities running 10-30% smaller and some a bit faster, with 64 bit libraries >for eg. Firefox.) My experiment should definitely not decide anything, but how >much real-world use would be sufficient to justify continued presence (more >complex compat code)? > >If left behind a flag like Debian (like the 2014 proposal >https://lore.kernel.org/lkml/[email protected]/), there >are no security risks so I understand the benefit is reduced code complexity >and maintenance burden. Older threads critiqued the implementation. What's the >smallest kernel support which would keep 32-bit pointers possible? Could a >small design (eg. just 32-bit pointers on x86-64 with i386's type layout, so >no 3rd compat case (cf. MIPS n32 and o32)) work? > >- Alex Alejandre
The thing is, we don't actually know. Therefore, if we are to keep x32, we need ***real users*** to speak up ***now*** and explain why they are using it and what the benefit to them is. With actual performance numbers. Otherwise it is not worth maintaining, partly because it apparently interferes with the convergence of the 32-bit ABIs, and the handful of x32-specific pieces of code do represent an additional attack surface. The desktop distros generally chafe under the 4 GB process limit, which means that an all-x32 desktop distro isn't very useful; having both x32 and x64 libraries defeats much of the x32 benefit, so the real use case is embedded or self-managed code bases. We are not going to go back in 2026 and redoing the *in retrospect* rather unfortunate choices made due to "Hinc Dictat Linus" early on (the original plan was to simply provide a fast way to access 32-bit syscalls from 64-bit mode and let the evolution of the compat ABI deal with things like time_t, but Linus objected to introducing a new ABI with 32-bit time_t, and at the time the time64_t interfaces were not yet there, so it ended up being an ad hoc implementation.)
