[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ebd51a5-e6c6-bba9-4608-fb5133ed15ab@adelielinux.org>
Date: Mon, 1 Jul 2019 09:50:31 -0500
From: "A. Wilcox" <awilfox@...lielinux.org>
To: musl@...ts.openwall.com
Subject: Re: Revisiting 64-bit time_t
On 07/01/19 09:41, Arnd Bergmann wrote:
> 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:
>>> 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)
>>> 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.
>
>
> Where would Adélie, Alpine and others using musl fit?
>
> Arnd
>
Adélie rebuilds all packages for every release, and encourages users to
use `apk upgrade -al` which will /replace/ all of world for every
upgrade, so we'd be very happy with b). Make everything as correct as
possible, as quickly as possible, with just a simple upgrade for users
(as long as they have no self-compiled software installed).
There is already no real "third-party" binary for 32-bit musl computers,
so I'm not sure if that's relevant. For glibc binaries, we have gcompat
which could easily "shadow" time_t functions with 32-bit versions for as
long as glibc binaries continue to have a need.
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
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.
