lkml.org 
[lkml]   [2015]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 00/24] ILP32 for ARM64
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


\
 
 \ /
  Last update: 2015-04-14 19:21    [W:0.113 / U:1.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site