Messages in this thread | | | From | Arnd Bergmann <> | Date | Wed, 14 Mar 2018 23:02:10 +0100 | Subject | Re: [PATCH 3/4] y2038: time: Introduce struct __kernel_old_timeval |
| |
On Sat, Mar 10, 2018 at 9:11 AM, Ingo Molnar <mingo@kernel.org> wrote: > >> +extern struct __kernel_old_timeval ns_to_kernel_old_timeval(const s64 nsec); > > Generally there's no need to mark arguments with arithmethic types as const, as > they are never modified in the calling scope.
Sure. Here I just copied from the neighboring line, but that's an obvious change.
>> + * legacy timeval structure, only embedded in structures that >> + * traditionally used 'timeval' to pass time intervals (not absolute >> + * times). Do not add new users. If user space fails to compile >> + * here, this is probably because it is not y2038 safe and needs to >> + * be changed to use another interface. >> + */ >> +struct __kernel_old_timeval { >> + __kernel_long_t tv_sec; /* seconds */ >> + __kernel_long_t tv_usec; /* seconds */ > > s/seconds/microseconds
Right.
>> +struct __kernel_old_timeval ns_to_kernel_old_timeval(const s64 nsec) >> +{ >> + struct timespec64 ts = ns_to_timespec64(nsec); >> + struct __kernel_old_timeval tv; >> + >> + tv.tv_sec = ts.tv_sec; >> + tv.tv_usec = (suseconds_t) ts.tv_nsec / 1000; > > Is ts.tv_nsec guaranteed to never have bits set in the high 32 bits?
Yes, ns_to_timespec64() produces a valid timespec64 structure.
> In any case, the space before the type cast is a bit confusing to me, I think it > should be written as: > > tv.tv_usec = (suseconds_t)ts.tv_nsec / 1000; > > To better show was the higher precedence of the cast is going to result in.
Sure.
Thanks for taking a look, I'll send an updated version.
Arnd
| |