On Fri, Dec 15, 2017 at 1:11 AM, Ben Hutchings ben.hutchings@codethink.co.uk wrote:
On Mon, 2017-11-27 at 11:30 -0800, Deepa Dinamani wrote:
--- a/include/uapi/linux/time.h +++ b/include/uapi/linux/time.h @@ -42,6 +42,13 @@ struct itimerval {
struct timeval it_value; /* current value */
};
+#ifndef __kernel_timespec +struct __kernel_timespec {
__kernel_time64_t tv_sec; /* seconds */long long tv_nsec; /* nanoseconds */+}; +#endif
I wonder if it makes sense to override the alignment of this structure? (64-bit types are aligned differently on 32-bit vs 64-bit x86, but not other compat cases.) It might reduce the need for conversions in compat code elsewhere later.
I think the alignment here should be agreed with glibc so they use the same alignment for their new timespec. I don't see a specific mention of this at https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#struct___timespec64 so I'm adding Albert and libc-alpha to Cc for clarification.
I agree it would simplify things a bit to ensure that time64_t and __timespec64/__kernel_timespec have a 64-bit alignment even on x86-32, but I don't know if there is precedent for using gcc __attribute__((aligned(8)) on POSIX data types, of if that might cause problems e.g. for non-gnu compilers.
Arnd