This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation
- From: Arnd Bergmann <arnd at arndb dot de>
- To: Lukasz Majewski <lukma at denx dot de>
- Cc: Joseph Myers <joseph at codesourcery dot com>, Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Florian Weimer <fweimer at redhat dot com>, Palmer Dabbelt <palmer at sifive dot com>, macro at wdc dot com, Zong Li <zongbox at gmail dot com>, Zong Li <zong at andestech dot com>, Alistair Francis <alistair23 at gmail dot com>
- Date: Thu, 27 Jun 2019 09:45:55 +0200
- Subject: Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation
- References: <cover.1561421042.git.alistair.francis@wdc.com> <4a1304510a5c9b5c2f6432bfdc5c9fd1740a081f.1561421042.git.alistair.francis@wdc.com> <CAK8P3a1fpqmFWMXAmV9KmuYFegRG958tLr9u=spELuRwXKfRiQ@mail.gmail.com> <20190625175125.03375ead@jawa> <CAK8P3a3AUgWzuZaZR5p2brmK16cMviidTf6A4aZ=mXVuNySbpA@mail.gmail.com> <20190626110711.64e8cd2f@jawa> <CAK8P3a0FVRV5H9f=wcU+C47R7FEckyjPtGVD2VaTAXsguEzyqw@mail.gmail.com> <20190626170344.2c9d1d47@jawa> <CAK8P3a2i1FktDrk1j5+qrTcUfqW=a=OviTVxyvTq8Vr0=Mw41Q@mail.gmail.com> <20190627005517.418d26c2@jawa>
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