[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 1 Jul 2019 16:41:51 +0200
From: Arnd Bergmann <arnd@...db.de>
To: musl@...ts.openwall.com
Subject: Re: Revisiting 64-bit time_t
On Sat, Jun 29, 2019 at 6:21 PM Rich Felker <dalias@...c.org> wrote:
> On Sat, Jun 29, 2019 at 03:36:19AM -0500, A. Wilcox wrote:
> > Overall this seems like a decent proposal. However...
> >
> > On Jun 28, 2019, at 10:06 AM, Rich Felker <dalias@...c.org> wrote:
> > > However Y2038 is not all that far off, desktop/server distros really
> > > have rather little interest left in 32-bit archs (especially not
> > > coordinating a costly ABI swap just for them)
> >
> > This is really incorrect. We at Adélie are QUITE interested in
> > 32-bit architectures including:
> >
> > Please, please do not write off 32-bit desktop usage.
>
> I'm sorry my wording contributed to a narrative that 32-bit is dead;
> that's not at all my intent, but I can see how it could be harmful to
> efforts to maintain support.
>
> My intent here is the other direction -- due to dominance of 64-bit
> archs on desktop and server these days, there's much less effort being
> put into the future of 32-bit ones, and I don't want to make a
> decision here that would incentivize distros that don't already care
> strongly about keeping 32-bit arch support to just drop it, rather
> than going through a painful ABI swap-out.
>
> Thanks for your work continuing to press applications not to break
> these archs.
I think there are three valid ways for distros to handle the time64
conversion for 32-bit targets:
a) Decide to never convert but keep the time32 until *all* users have
stopped using 32-bit user space altogether (i.e. well before 2038).
Advantage: no ABI break at all.
Disadvantage: guaranteed to break in 2038, but likely earlier
because of long timeouts like key expiration times.
b) System wide rebuild (bootstrap) against newer libc with time64.
Advantage: No surprising ABI break
Disadvantage: requires reinstall instead of all user space,
breaks all third-party and custom binaries
c) Keep backwards compatibility in libraries, but convert the
distro one package at a time.
Advantage: If done right, users can upgrade over rolling
releases without ABIs breaking
Disadvantage: very hard to get right, and much more work
than the other two.
It might be good to get feedback from distros using musl about
what model they each prefer. If everyone wants one of the first
two approaches anyway, that would simplify the implementation
in musl significantly. I assume that source based embedded
distros (e.g. openembedded, openwrt, possibly gentoo) are
usually happy with b), while most of the glibc based desktop
distros (Ubuntu, Red Hat, SUSE, ...) are ok with just dropping
32-bit support in the long run as in a) and would do that for
unrelated reasons. Debian will probably want c), but might also
be convinced to replace the existing 32-bit ports with musl based
ones to avoid the effort and reduce RAM usage at the same
time ;-)
Where would Adélie, Alpine and others using musl fit?
Arnd
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
