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

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 24 Jul 2019, Alistair Francis wrote:

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

What I'd like to see in the commit message is:

1. A detailed discussion of what the current ABI is regarding this 
argument (not how some systems used to use it for timezone handling, just 
how the Linux kernel handles it as an argument to the gettimeofday and 
settimeofday syscalls).

2. A discussion of how the patch achieves maximum ABI and API 
compatibility with existing programs using this argument (and in turn, the 
patch should be implemented so as to achieve that compatibility).  There, 
I'd suggest:

(a) For existing glibc ABIs, the tz value should continue to be passed to 
/ from the kernel exactly as at present (which might mean continuing to 
use the old syscalls when implementing those functions, even when newer 
syscalls are available - whether this value is passed to/from the kernel 
should not depend on __ASSUME_TIME64_SYSCALLS).

(b) For new ABIs, including _TIME_BITS=64 for systems that currently have 
32-bit time in glibc, you can make a reasonable case for not passing the 
argument to / from the kernel, at least if the special case mentioned in 
the settimeofday manpage for the hardware clock being in local time can be 
justified as being irrelevant for such ABIs.  But in this case I'd still 
think you should at least set *tz to some sensible default value in 
gettimeofday rather than leaving it as uninitialized data.

(Thus the tz argument might result in gettimeofday being an exception to 
the normal rule of 32-bit functions being thin wrappers around 64-bit 
ones, if the _TIME_BITS=64 version ends up handling tz differently from 
how the 32-bit syscall does.)

-- 
Joseph S. Myers
joseph@codesourcery.com