[PATCH v6] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Lukasz Majewski]

Hi Stepan,

> Resending as this was truncated yesterday.
> 
> 31.05.2019 в 14:49:02 +0400 Stepan Golosunov написал:
> > 30.05.2019 в 16:01:12 +0000 Joseph Myers написал:  
> > > 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.  
> > 
> > There is already a macro to specify whether semtimedop semantics is
> > available: __ASSUME_DIRECT_SYSVIPC_SYSCALLS.  It should be always
> > defined for 5.1+ kernels.  (Lack of support for
> > __NR_semtimedop_time64 in glibc is one of the obstacles in the way
> > of defining __ASSUME_DIRECT_SYSVIPC_SYSCALLS currently.)
> > 
> > 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.)

Please correct me if I'm wrong:

1. As we discussed the __ASSUME_TIME64_SYSCALLS is supposed to indicate
64 bit time support in a way that syscall ABI is the same for old and
new syscalls (there is no need to add any extra code in handling them).

2. The new syscalls - like semtimedop_time64, which need extra code for
handling, shall be excluded from __ASSUME_TIME64_SYSCALLS and hence
would receive new flag(s) - as proposed: __ASSUME_SEMTIMEDOP_TIME64

> > 
> > I fail to see how not using __ASSUME_TIME64_SYSCALLS can add
> > anything but extra complexity into the following logic:

Could you be more specific here (or rephase the above sentence)? 

> > __ASSUME_SEMTIMEDOP_TIME64
> > defined __ASSUME_TIME64_SYSCALLS
> >   && defined __ASSUME_DIRECT_SYSVIPC_SYSCALLS
> >   && defined __NR_semtimedop_time64:
> >     call semtimedop_time64
> > 
> > defined __ASSUME_TIME64_SYSCALLS
> >   && defined __ASSUME_DIRECT_SYSVIPC_SYSCALLS
> >   && !defined __NR_semtimedop_time64:
> >     call semtimedop
> > 
> > defined __ASSUME_TIME64_SYSCALLS
> >   && !defined __ASSUME_DIRECT_SYSVIPC_SYSCALLS:
> >     (must not happen when __LINUX_KERNEL_VERSION >= 0x050100)
> >     call ipc with IPCOP_semtimedop
> > 
> > !defined __ASSUME_TIME64_SYSCALLS
> >   && defined __ASSUME_DIRECT_SYSVIPC_SYSCALLS:
> >     try __NR_semtimedop_time64, fallback to 32-bit semtimedop
> > 
> > !defined __ASSUME_TIME64_SYSCALLS
> >   && !defined __ASSUME_DIRECT_SYSVIPC_SYSCALLS:
> >     try __NR_semtimedop_time64, fallback to 32-bit ipc with
> > IPCOP_semtimedop 

Now at sysdeps/unix/sysv/linux/semtimedop.c we do have:

#ifdef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
  return INLINE_SYSCALL_CALL (semtimedop, semid, sops, nsops, timeout);
#else
  return INLINE_SYSCALL_CALL (ipc, IPCOP_semtimedop, semid,
                              SEMTIMEDOP_IPC_ARGS (nsops, sops,
timeout));
#endif

And yes, this code would be more complicated when we follow the
conversion paradigm described here:

https://www.gnu.org/software/libc/manual/html_mono/libc.html#g_t64_002dbit-time-symbol-handling


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20190603/1fbe9e6e/attachment.sig>