This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Alistair Francis <alistair dot francis at wdc dot com>
- Cc: <libc-alpha at sourceware dot org>, <arnd at arndb dot de>, <adhemerval dot zanella at linaro dot org>, <fweimer at redhat dot com>, <palmer at sifive dot com>, <macro at wdc dot com>, <zongbox at gmail dot com>, <zong at andestech dot com>, <alistair23 at gmail dot com>
- Date: Wed, 24 Jul 2019 20:22:22 +0000
- Subject: Re: [RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable
- References: <cover.1561421042.git.alistair.francis@wdc.com> <cb015d0d1d29e4b948c7118c5b12ff2bed83a6ec.1561421042.git.alistair.francis@wdc.com>
On Mon, 24 Jun 2019, Alistair Francis wrote:
> Not all architectures support the obsolete gettimeofday so use the
> newer clock_gettime64 syscall if it is avaliable. This fixes RV32
> build issues.
A key question when using newer syscalls to implement gettimeofday or
settimeofday, which the commit message needs to answer, is: what are the
semantics for how the obsolete tz argument is handled, if not NULL?
I'd expect the proposed commit message to include a discussion of what the
semantics are for that obsolete argument in Linux kernel versions
supported by glibc, and what the semantics are for that argument in glibc
when some other syscall gets used by glibc.
For example, I'd expect that if tz is not NULL, any implementation using
other syscalls would at least fill in some dummy values in *tz, if that's
what the gettimeofday syscall would do. And on architectures where the
gettimeofday / settimeofday syscalls exist, if it is the case that some
information gets passed from settimeofday to gettimeofday through this
argument, I'd expect that information to continue to get passed through
rather than being lost through the use of newer syscalls. (You could
reasonably argue for not supporting anything with that argument in the
_TIME_BITS=64 case, but there could still be issues of keeping ABI
compatibility for this argument for existing ABIs with 32-bit time, unless
the current kernel semantics don't actually support doing anything with
this argument anyway. In any case, we need that explanation of current
semantics in order to review any semantic changes from the patch.)
--
Joseph S. Myers
joseph@codesourcery.com