Re: [PATCH v6] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Stepan Golosunov <stepan at golosunov dot pp dot ru>]

03.06.2019 в 17:28:51 +0000 Joseph Myers написал:
> 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.

Yes, in this form it won't work.

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

If "fallback code" means runtime fallback to 32-bit syscalls then this
won't work either.  And if it means any fallback code then some
condition for fallback to 32-bit syscalls is needed inside it.  Which
happens to be what __ASSUME_TIME64_SYSCALLS means otherwise.


If semantics for __ASSUME_TIME64_SYSCALLS is defined as "fallback to
syscalls with 32-bit time_t is not needed (and must not be used)" then
in most cases affected functions can be implemented as

#ifdef __ASSUME_TIME64_SYSCALLS
# ifndef __NR_foo_time64
#  define __NR_foo_time64 __NR_foo
# endif
/* Traditional implementation with foo replaced by foo_time64.  */
#else
/* Try foo_time64.  */
/* Convert input to 32-bit time_t.  */
/* Traditional implementation.  */
/* Convert output from 32-bit time_t.  */
#endif

This would work for semtimedop too (provided that definition of
__ASSUME_DIRECT_SYSVIPC_SYSCALLS is updated to reflect changes in
Linux 5.1).


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

Do you mean that __ASSUME_SEMTIMEDOP_TIME64 should be separate from
__ASSUME_TIME64_SYSCALLS so that they can have different wordings
explaining the same "fallback to syscalls with 32-bit time_t is not
needed" semantics?


Or should __ASSUME_TIME64_SYSCALLS for semtimedop be split into
__ASSUME_SEMTIMEDOP_TIME64 and __ASSUME_IPC_TIME64 so that
implementation replaces

__ASSUME_TIME64_SYSCALLS
__ASSUME_DIRECT_SYSVIPC_SYSCALLS

with

__ASSUME_SEMTIMEDOP_TIME64
__ASSUME_IPC_TIME64
__ASSUME_DIRECT_SYSVIPC_SYSCALLS

?