On Mon, 2017-11-27 at 11:30 -0800, Deepa Dinamani wrote:
> The new struct __kernel_timespec is similar to current
> internal kernel struct timespec64 on 64 bit architecture.
> The compat structure however is similar to below on little
> endian systems (padding and tv_nsec are switched for big
> endian systems):
>
> typedef s32 compat_long_t;
> typedef s64 compat_kernel_time64_t;
>
> struct compat_kernel_timespec {
> compat_kernel_time64_t tv_sec;
> compat_long_t tv_nsec;
> compat_long_t padding;
> };
>
> This allows for both the native and compat representations to
> be the same and syscalls using this type as part of their ABI
> can have a single entry point to both.
>
> Note that the compat define is not included anywhere in the
> kernel explicitly to avoid confusion.
If I understand correctly, the intent here is that C libraries will be
allowed to define struct timespec like that when appropriate feature
macros are enabled. Could you spell that out in the commit message,
and also the need to clear padding on the kernel side?
[...]
> --- 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.
Ben.
> /*
> * The IDs of the various system clocks (for POSIX.1b interval timers):
> */
--
Ben Hutchings
Software Developer, Codethink Ltd.
