Re: Can we drop upstream Linux x32 support?

On Wed, Dec 12, 2018 at 12:38 AM Thorsten Glaser [off-list ref] wrote:

Andy Lutomirski dixit:

quoted

What happens if someone adds a struct like:

struct nasty_on_x32 {
 __kernel_long_t a;
 void * __user b;
};

On x86_64, that's two 8-byte fields.  On x86_32, it's two four-byte
fields.  On x32, it's an 8-byte field and a 4-byte field.  Now what?

Yes, that’s indeed ugly. I understand. But don’t we already have
this problem with architectures which support multiple ABIs at the
same time? An amd64 kernel with i386 userspace comes to mind, or
the multiple MIPS ABIs.

The main trouble that I see with x32 is in how it's different
from all the other compat architectures. We have a number
of drivers that support not only two ABIs (native and compat)
but also a third one specifically for x32, and more drivers
that fail on x32 because they never implemented the third
case.

Note that this is not a problem for MIPS n32 and aarch64ilp32,
which generally stick to the regular compat ABI (each compat
architecture has some minor quirks somewhere, much less so
than x32 does).

quoted

actually do this work.  Instead we get ad hoc fixes for each syscall,
along the lines of preadv64v2(), which get done when somebody notices

Yes, that’s absolutely ugly and ridiculous and all kinds of bad.

On the other hand, from my current experience, someone (Arnd?) noticed
all the currently existing baddies for x32 already and fixed them.

I did some, and others did more, but it's hard to ever do a complete
job, and even harder to prevent new bugs from creeping in.

New syscalls are indeed an issue, but perhaps something generating
copyinout stubs could help. This might allow other architectures
that could do with a new ABI but have until now feared the overhead
as well. (IIRC, m68k could do with a new ABI that reserves a register
for TLS, but Geert would know. At the same time, time_t and off_t could
be bumped to 64 bit. Something like that. If changing sizes of types
shared between kernel and user spaces is not something feared…)

Creating a completely new ABI for an existing architecutre is generally
something you want to avoid, as this means all existing user space
has to be recompiled.

All architectures support 64-bit off_t already, and soon will support
64-bit time_t as well, at this point (as of this week's linux-next)
we mostly just need to assign a couple of syscall numbers for each
32-bit architectures.

        Arnd