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

Catalin Marinas
2015-04-20T15:56:07Z

On Fri, Apr 17, 2015 at 05:49:44PM +0200, Arnd Bergmann wrote:
> On Friday 17 April 2015 15:46:57 Catalin Marinas wrote:
> > On Fri, Apr 17, 2015 at 02:17:32PM +0100, Arnd Bergmann wrote:
> > > 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 think there is a much difference between g) and e). The reason
> > we re-define many structures in asm/compat.h is because we don't have a
> > generic compat_* definition (e.g. compat_timespec, compat_timeval,
> > compat_flock, compat_flock64; anyway, I think some of these may not even
> > be needed with the canonical set of syscalls). The signal related
> > structures need to be handled differently for AArch32 and AArch64-ILP32
> > anyway because of the difference in the register set.
>
> Interesting observation, I had not guessed this.
>
> Let's list the differences, this is what I could find:
>
> | #define FIOQSIZE 0x545E
>
> probably broken on arm64 already, should be investigated

Yes, it seems broken. arm64 uses the generic FIOQSIZE which doesn't
match the compat one.

> | typedef unsigned short __kernel_mode_t;
> | typedef unsigned short __kernel_ipc_pid_t;
>
> Both of these affect all sysvipc, but very little else
>
> | typedef unsigned short __kernel_uid_t;
> | typedef unsigned short __kernel_gid_t;
>
> sysvipc, ncpfs, and core dumps (probably fine since they are separate
> anyway),

Not all ipc functions are affected AFAICT. msgsnd, msgrcv, msgctl look
to me like we can just use the compat variants with the generic
definitions for the types above (unless I missed something). Similarly
for shmat, compat_sys_shmat just does some compat_ptr casting.

> | typedef unsigned short __kernel_old_dev_t; /* compat gets this wrong */
>
> old-style loopdev ioctl
>
> | struct stat { ... } /* possibly not needed */
>
> - lustre ioctls (needs to be fixed anyway)
> - old stat syscalls (won't be used with asm-generic/unistd.h)
>
> | struct stat64 { ... }
>
> - lustre ioctls
> - new style stat syscalls

For stat64 the wrappers don't look complicated, so we could add arm64
ILP32-specific ones.

I'm not sure about the ioctls affected, I haven't checked.

> So, in essence the difference comes down to the syscalls for stat
> and ipc. If we use the aarch32 data types, we can share the
> fstatat64, fstat64, semctl, msgsnd, msgrcv, msgctl, shmat,
> and shmctl compat system calls between aarch32-compat and
> aarch64-ilp32-compat. Otherwise we have to duplicate or extend
> them to cover both cases at runtime. That would be rather ugly
> but entirely doable. The ioctls are hardly affected, the few
> ones that differ once __kernel_long_t matches could easily be
> fixed up as you say.

I'd prefer a cleaner ABI even if we are to write some specific wrappers.

--
Catalin