Re: [PATCH] Patch 2 of 2 for ILP32 aarch64

[Florian Weimer <fweimer at redhat dot com>]

On 02/27/2017 05:48 PM, Arnd Bergmann wrote:
> On Mon, Feb 27, 2017 at 5:23 PM, Florian Weimer <fweimer@redhat.com> wrote:
> > On 02/22/2017 05:30 PM, Steve Ellcey wrote:
> > > +#define __TIME_T_TYPE          __SLONGWORD_TYPE
> >
> >
> > Does this mean time_t remains 32 bits?  Is this really a sane choice at this
> > point for a new architecture?
>
> Absolutely. We had a long discussion about this for the kernel port, and the
> conclusion is that we really need all types to be defined consistently across
> all architectures. If basic types like this were to differ between arm32 and
> arm64/ilp32, then we could not support both ABIs from a single kernel
> binary, as we can only have one set of compat syscall/ioctl ABI emulations
> at build time, and this is not likely to change anytime soon (x86 tried to
> do x32 and i386 emulation concurrently, but that support will probably never
> cover all device drivers).

So—some people are under the impression that aarch64 ILP32 doesn't need 
compat syscalls at all.  Are they wrong?

In any case, I understand that 32-bit time_t makes things easier for the 
kernel, but from a userspace perspective, it means that ILP32 is more or 
less dead on arrival as far as potential long-term support in 
(enterprise) distros goes.  Supporting new 32-bit architectures is a bit 
of a stretch at this point already, and the prospect of a hard ABI 
transition around ten years into the architecture/ABI lifetime isn't 
very compelling at all.

I really don't know what your expectations are.  If aarch64 ILP32 is 
just a toy, then I don't see a problem; the community cost for dragging 
it along do not seem that high.  But if there is a genuine expectation 
that it's going to be productized in some way, we might need something 
better.

Thanks,
Florian