Re: [PATCH v4 00/24] ILP32 for ARM64

[Arnd Bergmann <arnd@arndb.de>]

On Friday 17 April 2015 17:15:46 Dr. Philipp Tomsich wrote:
> More comments below.
> 
> > On 17 Apr 2015, at 16:46, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > 
> > Even in this case, we could enable AArch32 compat knowing that ioctls
> > wouldn't work. If this is important, we can add an option to enable
> > ioctl support for ILP32 and re-target the asm/compat.h definitions.
> > 
> >>  g) create a new ABI that does things in exactly the way that we
> >>     would use as the native syscall interface if we had an ilp32
> >>     kernel running on aarch64 with the asm-generic/unistd.h.
> >>     This would mean a 32-bit __kernel_long_t and time_t, but extending
> >>     time_t in the long run, together with aarch32 and i386.
> >>     This one is particularly interesting for people that are interested
> >>     in maximum posix compliance and in having a "nice" ABI, in particular
> >>     if there is a slight chance that within the next decade we have
> >>     reason to support building an arch/arm64 kernel itself in
> >>     aarch64-ilp32 mode.
> 
> I don’t believe that an ILP32 kernel wouldn’t use an uint64_t for time_t, as it
> has full support for 64bit arithmetic anyway.  I also believe that other kernel 
> internals (e.g. filesystems and inode-numbering) would use native 64bit types.
> 
> The differences on the kernel side would mainly rest in that only a 32bit address
> space could reasonably be managed. So a native ILP32 ABI would differ from
> the LP64 ABI mainly in how sizeof(long) is represented in the user-space.
> 
> In other works: a native ILP32 ABI on an ILP32 kernel would have a 64bit time_t.

We normally like to all newly architectures to have an identical ABI though,
which I think would be more important here. 64-bit time_t of course is what
we want all architectures to have in principle, but we didn't do it for nios2
because of the added complexity. I think it's more likely to have no
__kernel_time_t to defined at some point and only provide __kernel_time64_t
in the future for new architectures, but we have not even introduced that.

> >>>> However, it would be nice to get agreement on the normal 32-bit ABI
> >>>> for time_t and timespec first, and then use the same thing everywhere.
> >>> 
> >>> Do you mean for native 32-bit architectures? I think OpenBSD uses a
> >>> 64-bit time_t already on 32-bit arches, it's doable in Linux as well.
> >> 
> >> Yes, and I'm working on that for Linux. The first step involves fixing
> >> the kernel, one file at a time, changing all users of time_t to use
> >> some other type (ktime_t or time64_t in most cases) instead, and introducing
> >> additional system calls to handle the boundary to user space without
> >> breaking stuff. See my presentation at http://elinux.org/ELC_2015_Presentations
> >> for more detail.
> > 
> > The approach here is primarily to fix the problem for existing 32-bit
> > architectures by adding a new syscall and that's fine. But what if we
> > enforce 64-bit time_t for all _new_ architectures?
> 
> This boils down to whether we can define all the new syscalls _right now_ and
> get the new (extended) compat-layer set up. In this case we could have a userspace 
> implementation that already conforms to this for ILP32.
> 
> Otherwise, we can just put a (MIPS64) N32-alike (AArch64) ILP32 in and migrate
> with everyone else.
> 
> Although it feels wrong to add another ABI that has a known limitation, this may
> in fact be the easiest way, as any fix to ILP32 would be done together with the
> fixes to all other 32bit ABIs.
> 
> So, while I would like to have a 64bit time_t for ILP32 based on principle, I do see
> the 32bit time_t path as the most pragmatic way forward… especially, as this unlinks
> getting “some form of” ILP32 merged from resolving the 64bit time_t issue across
> all architectures.

Given Catalin's comments from yesterday, I think we can just fix the
definitions of 'struct stat64' for asm-generic to make it have the same
layout as the 64-bit version of 'struct stat', and use that for aarch64-ilp32.

Similarly for the four sysvipc headers, we can have a modified version of
the asm-generic ones in arch/arm64/uapi/asm, which will use the same layout
for ilp32 and lp64 without having to set __kernel_ulong_t to 64-bit.

	Arnd