Re: [RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable

[Alistair Francis <alistair23 at gmail dot com>]

On Wed, Jul 24, 2019 at 1:22 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> 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.

Yep, I missed this. I have already added it to the commit message of
the next version.

    This has the side effect of not setting the struct timezone *tz variable
    if __ASSUME_TIME64_SYSCALLS or __NR_clock_gettime64 is defined. There
    are two things to consider here:
     - 32-bit systems with __ARCH_WANT_TIME32_SYSCALLS not defined have to
       way to get the struct timezone via a syscall.
     - The Linux documentation says that "The use of the timezone structure
       is obsolete; the tz argument should normally be specified as NULL."
       So let's not worry about it.

Alistair

>
> 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