Re: [PATCH v6] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 29 May 2019, Lukasz Majewski wrote:

>   List of new syscalls added to v5.1. kernel (they accept data based on
>   struct timespec and timeval with 64 bit tv_sec):
> 
>    clock_gettime64
>    clock_settime64
>    clock_adjtime64
>    clock_getres_time64
>    clock_nanosleep_time64
>    timer_gettime64
>    timer_settime64
>    timerfd_gettime64
>    timerfd_settime64
>    utimensat_time64
>    pselect6_time64
>    ppoll_time64
>    io_pgetevents_time64
>    recvmmsg_time64
>    mq_timedsend_time64
>    mq_timedreceive_time64
>    semtimedop_time64
>    rt_sigtimedwait_time64
>    futex_time64
>    sched_rr_get_interval_time64

I do *not* think semtimedop_time64 should be included in the set of 
syscalls.  I think that if the macro is defined on systems with __WORDSIZE 
== 64, it should *only* relate to syscalls where the syscall semantics are 
*identical* for both the old syscall (on systems where __WORDSIZE or 
__SYSCALL_WORDSIZE is 64) and for the new one, so that no code will ever 
have to handle the two syscalls differently.  And the comment should 
explicitly say that it is only for that subset of syscalls.

I also think the list has to go in the comment defining the semantics, not 
just the commit message, to make clear exactly what syscalls are covered - 
and thus that it does not cover any other syscalls relating to time that 
may be added in later kernel versions.

> In other words the __ASSUME_TIME64_SYSCALLS does not indicate the presence
> of particular syscalls, but the generic ability which they provide (64 bit
> time support).

The whole point of __ASSUME_* macros is to indicate availability of 
specific interfaces - syscalls, in this case.  It simply happens that the 
name of the syscalls in question depends on the architecture.

> +/* This flag indicates support for Linux kernel syscalls, which are able
> +   to handle 64 bit time ABI. It is defined for architectures with both
> +   intrinsic 64 bit time support as well as ones gaining it with new
> +   syscalls added to Linux kernel version 5.1.

"intrinsic 64 bit time support" is the sort of vague description that does 
not belong anywhere in code related to time in glibc.  The support on 
architectures where the syscalls have a name involving "64" is neither 
more nor less intrinsic than the support on architectures where the 
syscalls have names not involving "64".

I think you mean syscall ABIs (not architectures, this depends on the ABI 
for some architectures) for which the size of "long int" is 64-bit.  The 
size of "long int" for the syscall ABI, in turn, is always the same as the 
size of "long int" in the userspace ABI, except for x32.

-- 
Joseph S. Myers
joseph@codesourcery.com