This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2 2/7] y2038: Introduce __ASSUME_64BIT_TIME define


06.05.2019 в 16:26:59 +0200 Lukasz Majewski написал:

> > > > > > I believe that the only 32-bit architecture without
> > > > > > __NR_clock_settime64 is x32.       
> > > > > 
> > > > > Ok, I see. 
> > > > > 
> > > > > Please correct me - would it be feasible to just #undef
> > > > > __ASSYME_TIME64_SYSCALLS for x32 ?      
> > > > 
> > > > You'll need to know whether to use __NR_clock_settime64 or
> > > > __NR_clock_settime in cases where __TIMESIZE == 64 and
> > > > __WORDSIZE == 32.  
> > 
> > Please correct me, but I do have some doubts here.
> > 
> > As x32 now uses 64 bit time (and has TIMESIZE==64) - it uses the
> > clock_settime call (with in-kernel broken tv_nsec padding clearing -
> > but for this the fix is in its way to upstream).
> > 
> > Why does it need to also support clock_settime64 ? 
> 
> I was too eager to send the mail.
> 
> It is connected with your proposition to use __WORDSIZE for #ifdef on
> __ASSUME_TIME64_SYSCALLS. 
> 
> As x32 has __WORDSIZE=32 (but __TIMESIZE=64), it would fall into
> "category" of archs using explicit 64 bit calls (i.e. clock_settime64).
> 
> However, for it - those shall be replaced with syscalls used up till now
> (i.e. clock_settime).
> 
> Am I right here ?

x32 has __WORDSIZE==32 and __TIMESIZE==64.  Future 32-bit
architectures should have __WORDSIZE==32 and __TIMESIZE==64 too.  And
the only difference in implementation of clock_settime64 function there
should be name of syscall (ignoring possible padding clearing
issues).

> > > > One way would be by defining __ASSUME_TIME64_SYSCALLS
> > > > unconditionally on x32 and then defining __NR_clock_settime64 to
> > > > __NR_clock_settime when __ASSUME_TIME64_SYSCALLS is defined while
> > > > __NR_clock_settime64 isn't.

I think now that with this scheme __ASSUME_TIME64_SYSCALLS should be
defined unconditionally for the __WORDSIZE==64 case too.  With this
there will be no need to use __TIMESIZE inside clock_settime64
function.  __TIMESIZE describes interfaces provided by glibc, and has
no relation with kernel interfaces used by glibc.

#ifdef __ASSUME_TIME64_SYSCALLS
  call __NR_clock_settime64 (possibly defined to __NR_clock_settime)
#else
  call __NR_clock_settime64 with fallback to __NR_clock_settime on ENOSYS
#endif


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]