[PATCH] Patch 2 of 2 for ILP32 aarch64
Florian Weimer
fweimer@redhat.com
Tue Feb 28 17:46:00 GMT 2017
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
More information about the Libc-alpha
mailing list