lkml.org 
[lkml]   [2015]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Y2038] [PATCH 04/11] posix timers:Introduce the 64bit methods with timespec64 type for k_clock structure
On Tue, 21 Apr 2015, Arnd Bergmann wrote:
> 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

So you want to avoid a compat syscall for 32bit applications on a
64bit kernel, right?

That burdens 32bit with the extra 'long long' in user space. Not sure
whether user space folks will be happy about it.

> * 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.

Fair enough.

> * 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.

Makes sense.

Thanks,

tglx


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