Re: [PATCH v6] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Lukasz Majewski <lukma at denx dot de>]

Hi Stepan, Joseph,

> 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

If I understood correctly the __ASSUME_TIME64_SYSCALLS is defined as:

It indicates 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).

Moreover, if it is defined, there is no need for 32 bit time_t syscalls
(and those must not be used).

With such definition we can follow below pattern (similar to the
already posted code for clock_settime):

> 
> #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
> 
> ?

Is there any idea on how to solve the above problem?


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

Attachment: pgp2m9sfjyRPc.pgp
Description: OpenPGP digital signature