Re: [Y2038] [PATCH 04/11] posix timers:Introduce the 64bit methods with timespec64 type for k_clock structure

[Arnd Bergmann]

On Tuesday 21 April 2015 16:14:26 Thomas Gleixner wrote:
> > Note the use of a separate __kernel_itimerspec64 for the user interface
> > here, which I think will be needed to hide the differences between the
> > normal itimerspec on 64-bit machines, and the new itimerspec on 32-bit
> > platforms that will be defined differently (using 'long long').
> 
> Confused.
> 
> timespec64 / itimerspec64 should be the same independent of 64bit and
> 32bit. So why do we need another variant ?

There are multiple reasons:

* On 64-bit systems, timespec64 would always be defined in the same way
  as struct timespec { __kernel_time_t tv_sec; long tv_nsec; }, with
  __kernel_time_t being 'long'. On 32-bit, we probably need to make both
  members 'long long' for the user space side, in order to share the
  syscall implementation with the kernel side, but we may also want to
  keep the internal timespec64 using a 'long' for tv_nsec, as we do
  today. This means that both the binary layout (padding or no padding)
  and the basic types (long or long long) are different between 32-bit
  and 64-bit, and between kernel and user space
* We should not put 'struct timespec64' into the user space namespace,
  as applications might already use that identifier. This is similar
  to the __u32/u32 or __kernel_time_t/time_t tuple of types for interface
  and in-kernel uses. This is particularly important when embedding a
  timespec in another data structure.
* My plan is to use a temporary hack where I actually define
  __kernel_timespec64 to look like the 32-bit version of timespec,
  as an intermediate step when converting all 32-bit architectures over
  to use the compat_*() syscalls in place of the existing ones, so
  I can change over the normal syscalls to use __kernel_timespec64
  without having to change all architectures at once, or having to
  modify each syscall multiple times.

> > I would also prefer not too many people to work on the syscalls, and
> > would rather have Baolin not touch any of the syscall prototypes for
> > the moment.
> 
> I did not ask him to change any of the syscall prototypes. I just
> wanted him to split out the guts of the syscall into a seperate static
> function to avoid all that code churn.

Ok, I wasn't sure about that part, thanks for clarifying.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/