Re: [PATCH v5] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 2625 bytes --]

Hi Joseph,

> On Sat, 25 May 2019, Stepan Golosunov wrote:
> 
> > In most cases code can look like this:
> > 
> > #ifdef __ASSUME_TIME64_SYSCALLS
> > #ifndef __NR_clock_settime64
> > #define __NR_clock_settime64 __NR_clock_settime
> > #endif
> > INLINE_SYSCALL_CALL (clock_settime64, …)
> > #else
> > try clock_settime64, if that fails (whether compiletime or runtime)
> > convert data to 32-bit, call clock_settime
> > #endif
> > 
> > (Yes, for semtimedop it won't be that simple.  Because traditional
> > syscall isn't semtimedop in some cases.  This also assumes that
> > the  
> 
> If we follow this approach, it would be reasonable to say that 
> __ASSUME_TIME64_SYSCALLS is *only* for those syscalls where the old 
> syscall, on platforms that had 64-bit time in their syscall interface
> all along, is exactly equivalent (and to list that subset) 

Yes, I do agree. Also those syscalls shall be explicitly listed in the
commit message and code (as comments).

> - not for 
> semtimedop.  Then there could be a separate
> __ASSUME_SEMTIMEDOP_TIME64.
> 
> > 20 time64 syscall names won't suddenly be added to kernel headers
> > for 64-bit ABIs.)  
> 
> Rather, that they won't be added *with new syscall numbers*.  If the 
> kernel adds them as macro aliases for the old syscall numbers, code
> like that would work just fine.  If the kernel adds them as new
> syscall numbers, the definition of __ASSUME_TIME64_SYSCALLS (that
> assumes it can always be true for existing 64-bit syscall ABIs) would
> suddenly become wrong when using new kernel headers, because it would
> result in glibc code using new syscall numbers without regard to a
> possibly older runtime kernel version.
> 

Maybe I'm missing something, but would there be any use case
(possibility) that for archs supporting 64 bit time ABI (and using e.g.
__NR_clock_settime now) the new syscalls (like __NR_clock_settime64),
with the same functionality, would be added with different numbers?

Why already perfectly working __NR_clock_settime would be replaced by
other syscall (like __NR_clock_settime64) not with alias but different
number (on e.g x86_64)?

I always thought that __NR_clock_settime64 would be added on archs with
__WORDSIZE==32 to allow them to work after Y2038 and hence there would
be no chance for such collision.


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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]