On Mon, Mar 20, 2017 at 9:40 PM, Thomas Gleixner tglx@linutronix.de wrote:
On Mon, 20 Mar 2017, Deepa Dinamani wrote:
-static int ptp_clock_getres(struct posix_clock *pc, struct timespec *tp) +static int ptp_clock_getres(struct posix_clock *pc, struct timespec64 *tp)
That's a pretty pointless exercise. getres() returns the resolution of the clock which obviously can never be affected by Y2038.
True, tv_sec does not need to be more than 32 bits here. We plan to limit the use of struct timespec to existing user interfaces only.
This is an existing user space interface and there is no need to change it at all.
I think we should change it in the kernel, otherwise every libc implementation has to include a copy of this, to convert between the user space 16-byte timespec and the 8-byte kernel timespec. If we do it in the kernel, we only need one copy and the interface is consistent between 32-bit and 64-bit user space.
The other point that Deepa made is important for verification purposes: If we can eliminate timespec/time_t/timeval from all in-kernel code, we have a much better chance at showing that we have no y2038 problems. I did a private patch series to try this out a while ago, and managed to actually get the kernel to build fine with no 32-bit time_t code left in it (lots of minor drivers being marked in Kconfig as depending on old time_t)
Arnd