From: Thomas Gleixner
> Sent: 22 April 2015 09:45
> On Tue, 21 Apr 2015, Thomas Gleixner wrote:
> > On Tue, 21 Apr 2015, Arnd Bergmann wrote:
> > > I know there are concerns about this, in particular because C11 and
> > > POSIX both require tv_nsec to be 'long', unlike timeval->tv_usec,
> > > which is a 'suseconds_t' and can be defined as 'long long'.
> > >
> > > a)
> > >
> > > struct timespec {
> > > time_t tv_sec;
> > > long long tv_nsec; /* or typedef long long snseconds_t */
> > > };
> > >
> > > This is not directly compatible with C11 or POSIX.1-2008, but it
> > > matches what we do inside of 64-bit kernels, so probably has the
> > > highest chance of working correctly in practice
> >
> > After reading Linus rant in the x32 thread again (thanks for the
> > reminder), and looking at b/c/d - which rate between ugly and butt
> > ugly - I think we should go for a) and screw POSIX and C11 as those
> > committee dinosaurs seem to completely ignore the 2038 problem on
> > 32bit machines. At least I have not found any hint that these folks
> > care at all. So why should we comply to something which is completely
> > useless?
> >
> > That also makes the question about the upper 32bits check moot, so
> > it's the simplest and clearest of the possible solutions.
>
> Second thoughts after some sleep.
>
> So the outcome of this is going to be that user space libraries will
> not expose the syscall variant of
>
> syscall_timespec64 {
> s64 tv_sec;
> s64 tv_nsec;
> };
>
> to applications. The libs will translate them to spec conforming
>
> timespec {
> time_t tv_sec;
> long tv_nsec;
> };
>
> anyway. That means we have two translation steps on 32bit systems:
>
> 1) user space timespec -> syscall timespec64
>
> 2) syscall timespec64 -> scalar nsec s64 (ktime_t)
>
> and the other way round. The kernel internal representation is simply
> s64 (nsec) based all over the place.
Do you need the double-translation?
If all the kernel uses a 64bit nsec value the in-kernel syscall stub
can convert the user-supplied values appropriately before calling
the standard function.
Not that a syscall that takes a linear nsec value isn't useful.
FWIW I can't remember what NetBSD did when they extended time_t to 64bits.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
