From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27105 invoked by alias); 25 Jul 2019 21:23:54 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 27097 invoked by uid 89); 25 Jul 2019 21:23:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: relay1.mentorg.com Date: Thu, 25 Jul 2019 21:23:00 -0000 From: Joseph Myers To: Alistair Francis CC: Alistair Francis , GNU C Library , Arnd Bergmann , Adhemerval Zanella , Florian Weimer , Palmer Dabbelt , , Zong Li , Zong Li Subject: Re: [RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2019-07/txt/msg00603.txt.bz2 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