From: Thomas Gleixner

Sent: 22 April 2015 09:45
On Tue, 21 Apr 2015, Thomas Gleixner wrote:

quoted

On Tue, 21 Apr 2015, Arnd Bergmann wrote:

quoted

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.

=20
Second thoughts after some sleep.
=20
So the outcome of this is going to be that user space libraries will
not expose the syscall variant of
=20
    syscall_timespec64 {
           s64 tv_sec;
	   s64 tv_nsec;
    };
=20
to applications. The libs will translate them to spec conforming
=20
   timespec {
           time_t tv_sec;
	   long   tv_nsec;
   };
=20
anyway. That means we have two translation steps on 32bit systems:
=20
  1) user space timespec -> syscall timespec64
=20
  2) syscall timespec64 -> scalar nsec s64 (ktime_t)
=20
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