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.
On Fri, Dec 15, 2017 at 1:11 AM, Ben Hutchings
<[email protected]> 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