Re: [PATCH v6] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Lukasz Majewski <lukma at denx dot de>]

Hi Joseph, Stepan

> On Tue, 4 Jun 2019, Stepan Golosunov wrote:
> 
> > > 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?  
> 
> It might well have a different definition as well, depending on what 
> semantics make the most sense for it.
> 
> It's entirely OK to define some __ASSUME_* macros in terms of other 
> __ASSUME_* macros, if that helps make the different cases and their 
> relations clearer.  (E.g. look at the sets of macros we used to have 
> relating to accept4, recvmmsg, sendmmsg, to deal with cases where
> they might sometimes be available with socketcall but not with a
> syscall, until the minimum kernel version became recent enough that
> we could always assume the functionality, if not a syscall for it, to
> be available, and so could simplify the code.)
> 
> __ASSUME_TIME64_SYSCALLS should have the simplest, clearest semantics
> that work for its purpose.  If any syscall needs something slightly
> different, it's appropriate to separate it out.  That includes if the
> previous versions of any of the other syscalls listed for
> __ASSUME_TIME64_SYSCALLS were not in fact present in 3.2 for all
> architectures supported by glibc (something I haven't checked, but
> which needs to be checked) - if any syscall has that as a
> complication, take it out of the list to which
> __ASSUME_TIME64_SYSCALLS applies and deal with that complication
> separately, later.
> 

Can we assume the above sentence as a "consensus" for
__ASSUME_TIME64_SYSCALLS semantics definition ?

Or are there any other open topics for discussion?

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: pgpNhD8u975_c.pgp
Description: OpenPGP digital signature