Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Lukasz Majewski <lukma at denx dot de>]

Hi Arnd

> On Thu, Jun 27, 2019 at 12:55 AM Lukasz Majewski <lukma@denx.de>
> wrote:
> > > On Wed, Jun 26, 2019 at 5:03 PM Lukasz Majewski <lukma@denx.de>
> > > wrote:  
> > > > > On Wed, Jun 26, 2019 at 11:07 AM Lukasz Majewski
> > > > > <lukma@denx.de> wrote:  
> > > > > > > On Tue, Jun 25, 2019 at 5:51 PM Lukasz Majewski
> > > > > > > <lukma@denx.de>  
> > > > > >
> > > > > > Shouldn't those syscalls be kept until the minimal supported
> > > > > > glibc kernel version is 5.1?  
> > > > >
> > > > > We will probably keep them as an option in the kernel until
> > > > > 2038, but leave it to the distro or embedded system design to
> > > > > turn them on or off.  
> > > >
> > > > Isn't this the ABI break on demand ?  
> > >
> > > It's removing an unused ABI in order to ensure that nothing uses
> > > it. The policy is to never break things that users rely on, so
> > > you should only disable the system calls if you control all of
> > > user space and want to ensure that whatever works now doesn't
> > > break in the future.  
> >
> > In other words use glibc to help with validation of the system by
> > disabling (by kernel option) the time32 syscalls and check what
> > happens?  
> 
> Yes. [ Even better would be a compile-time option to just leave out
> the time32 support from glibc entirely, but as I understand that will
> not be possible until most users have moved over to time64,
> and users can't wait for that to do validation on products shipping
> now. ]
> 
> Mostly this means to just not put in code to support a case that
> nobody cares about (running time32 applications on pure time64
> systems), so I would not expect this to cause extra effort in
> development, just a little care with the implementation.
> 
> 
> > > > > However, there is the problem that in some point in time the
> > > > > glibc will switch to 64 bit __TIMESIZE only (probably when
> > > > > minimal kernel version for glibc would be grater than 5.1) and
> > > > > all __clock_settime syscalls would be served with
> > > > > __clock_settime64 (as 64 bit time support is always in place).
> > > > >
> > > > > After this switch the "unconverted" program will setup wrong
> > > > > time.  
> >
> > I'm still not following. Which of steps listed below would that
> > correspond to? I guess the last one, right?
> >  
> > > > > - drop support for building with time32  
> >         ^^^ TIMESIZE == 64 (no support for time32)
> >
> > (But this need ACK from e.g. Joseph if I understood it correctly).  
> 
> I still don't see how that would break anything: if applications
> are all built with 64-bit time_t, they would not call into the old
> __clock_settime() function, which is then only kept around
> for compatibility with old binaries and would still operate on
> 32-bit time_t and use __NR_clock_settime.
> 
>       Arnd

After the discussion I do believe that it would be correct to change
the proposed patch [1] '__clock_settime' to:

#if __TIMESIZE != 64
int
__clock_settime (clockid_t clock_id, const struct timespec *tp)
{
/* For archs with WORDSIZE==32, which do not support clock_settime64
the clock_settime supporting 32 bit time ABI will be used */

return INLINE_SYSCALL_CALL (clock_settime, clock_id, tp);
}
#endif  


The "__clock_settime64()" part could be left untouched.


Note:

[1] - https://patchwork.ozlabs.org/patch/1107235/

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