This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v6] y2038: Introduce __ASSUME_TIME64_SYSCALLS define
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Stepan Golosunov <stepan at golosunov dot pp dot ru>
- Cc: Lukasz Majewski <lukma at denx dot de>, <libc-alpha at sourceware dot org>, Arnd Bergmann <arnd at arndb dot de>, Paul Eggert <eggert at cs dot ucla dot edu>
- Date: Mon, 3 Jun 2019 17:28:51 +0000
- Subject: Re: [PATCH v6] y2038: Introduce __ASSUME_TIME64_SYSCALLS define
- References: <20190529122200.19883-1-lukma@denx.de> <alpine.DEB.2.21.1905301553050.13569@digraph.polyomino.org.uk> <20190531104902.xlsfw2isd6q4mspa@sghpc.golosunov.pp.ru> <20190601110045.3ienooysoe4mj2gc@sghpc.golosunov.pp.ru>
On Sat, 1 Jun 2019, Stepan Golosunov wrote:
> > I see how splitting semtimedop/semtimedop_time64
> > availability from __ASSUME_DIRECT_SYSVIPC_SYSCALLS can help to
> > untangle __ASSUME_DIRECT_SYSVIPC_SYSCALLS from time64. (It would
> > probably be overkill though—in the end splitted macro would be defined
> > exactly at the same time as __ASSUME_DIRECT_SYSVIPC_SYSCALLS.)
> >
> > I fail to see how not using __ASSUME_TIME64_SYSCALLS can add anything
> > but extra complexity into the following logic:
The basic rule, for each syscall covered by __ASSUME_TIME64_SYSCALLS, if
we use the semantics that __ASSUME_TIME64_SYSCALLS is defined
unconditionally for existing 64-bit syscall ABIs, is that the following is
always OK:
#ifdef __ASSUME_TIME64_SYSCALLS
# ifndef __NR_foo_time64
# define __NR_foo_time64 __NR_foo
# endif
/* Implementation that uses foo_time64 unconditionally. */
#else
/* Implementation that needs fallback code. */
#endif
My understanding is that this would not work for semtimedop, because not
all 64-bit syscall ABIs have __NR_semtimedop. (Or, equivalently, it would
work for semtimedop *only* if the syscall ABIs in question avoided
defining __ASSUME_TIME64_SYSCALLS before Linux 5.1 - but since those ABIs
do have the other syscalls, that wouldn't be helpful.)
Splitting semtimedop out of what the comment on __ASSUME_TIME64_SYSCALLS
says its semantics are seems cleaner to me than having more complicated
semantics that are different as regards semtimedop than as regards all the
other syscalls. You can then have __ASSUME_SEMTIMEDOP_TIME64 with a
comment explaining exactly what the semantics of that macro are for 64-bit
syscall ABIs without a semtimedop syscall.
Note: I haven't verified if all 64-bit syscall ABIs did have all the other
syscalls in the list as of Linux 3.2, or if any other cases should also be
split out.
--
Joseph S. Myers
joseph@codesourcery.com