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

[Catalin Marinas <catalin.marinas@arm.com>]

On Tue, Apr 14, 2015 at 05:29:36PM +0200, Dr. Philipp Tomsich wrote:
> > On 14 Apr 2015, at 16:47, Catalin Marinas <catalin.marinas@arm.com> wrote:
> >> I mainly want to avoid accidentally creating new ABIs for syscalls and ioctls:
> >> we have many drivers that today use ioctls with data structures derived from
> >> '__kernel_ulong_t' in some form, often by including a timespec or time_t in
> >> their own data structures. These are almost all broken today, because the
> >> data structures are a mix of the aarch32 and aarch64 variants, while the
> >> ioctl() system call in ilp32 always uses the aarch32 format by default.
> >> 
> >> An example here would be 
> >> 
> >> struct cyclades_idle_stats {
> >>    __kernel_time_t in_use;     /* Time device has been in use (secs) */
> >>    __kernel_time_t recv_idle;  /* Time since last char received (secs) */
> >>    __kernel_time_t xmit_idle;  /* Time since last char transmitted (secs) */
> >>    unsigned long  recv_bytes;  /* Bytes received */
> >>    unsigned long  xmit_bytes;  /* Bytes transmitted */
> >>    unsigned long  overruns;    /* Input overruns */
> >>    unsigned long  frame_errs;  /* Input framing errors */
> >>    unsigned long  parity_errs; /* Input parity errors */
> >> };
> >> 
> >> for a random ancient driver. Introducing a third set of data structures
> >> and syscalls for aarch64-ilp32 means that any driver doing something like
> >> this needs to be modified to support existing user space source code.
> > 
> > That's indeed a problem as ILP32 doesn't look like any of the other
> > options (the siginfo structure is another case that doesn't fit in any
> > of the ABI as long as time_t is 64-bit).
> 
> I believe we’ve already arrived at the conclusion that timespec needs to be
> changed from what Andrew and I had submitted. 
> 
> Let’s go back to the underlying definition of timespec:
> 	"The range and precision of times representable in clock_t and time_t are 
> 	implementation-defined. The timespec structure shall contain at least the
> 	 following members, in any order.
> 
> 	         time_t tv_sec; // whole seconds -- >= 0
> 	         long   tv_nsec; // nanoseconds -- [0, 999999999]”
> 
> So tv_nsec needs to be 32bit on ILP32, as we would otherwise break the C
> language.  Any program that assumes that tv_nsec is sizeof(long) would be
> correct and it would be unexpected and surprising behaviour [even though it
> would be consider a good programming style] if one would need to explicitly 
> ask for the sizeof(ts.tv_nsec). Having the same problem on x32 doesn’t seem 
> like a good justification to do the same.

>From a standards perspective, that's clear, and I'm fine with not making
the same choice as x32. I think on x32 it was a side-effect of glibc
defining tv_nsec as __syscall_slong_t and the kernel defining
__kernel_long_t to 64-bit.

> For time_t, I don’t see the need to have a 32bit type yet.
> As long as the the type is properly exposed through header files (and user
> programs can thus recreate the kernel’s data model), we should be safe.

The problem with a 64-bit time_t is that the timespec structure looks
like neither compat32 nor native 64-bit. If we make the AArch32 and
native ILP32 exclusive and build time, it makes it easier, otherwise we
need to support a third ABI in the kernel.

> The key to any design decision should be that we 
>  (a) don’t break C11, POSIX or the Single UNIX Specification
>  (b) remain true to the definitions from the the AArch64 ILP32 ELF ABI 
> 	(which defines	64bit values transferable in registers to callees)

I think these are fine.

> Can we thus agree on the following for the next revision of the patch-set:
>  (1) We retain a 64bit time_t, but implement different sizes (between ILP32 and 
> 	LP64) for ‘tv_nsec' in 'struct timespec’?
>  (2) We use the 64bit system calls whereever possible (i.e. no register splitting).

As I mentioned above, timespec and possibly other structures no longer
like any of the existing ABIs. Do we know how many syscalls are
affected?

The alternative is 32-bit time_t which makes it easier to use the compat
syscall implementations (not numbers). It also depends on how we plan to
fix the 2038 problem. For new 32-bit only architectures, are we going to
require them to use a 64-bit time_t or we get alternative time64_t and
timespec64 specs?

-- 
Catalin