From: Arnd Bergmann <arnd@arndb.de>
To: Wolfgang Denk <wd@denx.de>
Cc: Florian Weimer <fweimer@redhat.com>,
GNU C Library <libc-alpha@sourceware.org>,
Lukasz Majewski <lukma@denx.de>
Subject: Re: Accelerating Y2038 glibc fixes
Date: Wed, 17 Jul 2019 16:15:25 +0200 [thread overview]
Message-ID: <CAK8P3a3mdzYBw_1geg67MpkhpVLkqqqqB3q+rbmgW4gvDsO4UA@mail.gmail.com> (raw)
In-Reply-To: <20190716145216.1C7CE240085@gemini.denx.de>
On Tue, Jul 16, 2019 at 4:52 PM Wolfgang Denk <wd@denx.de> wrote:
> In message <874l3mjgi6.fsf@oldenburg2.str.redhat.com> you wrote:
>
> > Since I'm opposed to this entire project, I have largely refrained from
> > reviews, except for things that looked obviously wrong to me (e.g.,
> > things that definitely break compatibility with older kernels or
> > existing ABIs), but even for those cases, my feedback probably wasn't
> > very helpful.
>
> I can understand your point of view, but indeed this is not helpful
> here. glibc is a central resource for the whole FOSS system, and we
> are not pushing these changes for a fancy, but because a solution
> is needed for a large number of affected projects and products.
>
> We need to find a constructive way to proceed with this matter. It
> will not go away if we try to ignore it.
My impression is that we have two mostly separate groups
of users for 32-bit user space:
a) Those that absolutely require 100% ABI compatibility to run
legacy code but will eventually migrate to 64-bit user space,
almost certainly within the coming ten years before we really
need to worry (too much) about things like key expiration dates
beyond 2038.
b) Those that already need support for 64-bit time_t because
they are deploying new 32-bit binaries that are expected to run
beyond 2038, while not caring at all about compatibility
with existing binaries that are already known to be broken
for this purpose.
If we just work to satisfy both these groups but ignore the intersection
(those that have existing 32-bit binaries and want those to run
after 2038?), things could become noticeably easier.
The price for that is a mid-2030s EOL time on any existing 32-bit
glibc ports, any binaries linked to them, and any distros built upon
that, and replacing them with something else that is binary
incompatible but can coexist within e.g. a container.
There are several options what such a replacement might look
like, some that come to mind would include:
- A patchset against glibc that replaces all the time32 interfaces
with time64 ones and that is maintained outside of the glibc
code base by whoever is interested in this working.
- A set of glibc architecture ports that can coexist with the
existing ports but have new target triples and/or soname.
These could be implemented and merged one architecture
at a time and share most of the code with the existing
ports.
- Leave glibc unchanged and require users/distros to migrate to
musl or something else if they need the time64 support.
Any of the above approaches (including the current plan of
supporting time32 and time64 in a single glibc binary) can of
coexist, but the more incompatible approaches get implemented,
the more fragmentation of ABIs we get.
Note that we have never had such a forced transition on x86, but
there are several examples on other architectures:
- arm oabi/gnueabi/gnueabihf
- ppc64/ppc64le
- mips o32/n32/64
The migration is not much fun for users to say the least, but it's
quite possible that the alternative is even worse.
Arnd
next prev parent reply other threads:[~2019-07-17 14:16 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-12 7:21 Accelerating Y2038 glibc fixes Wolfgang Denk
2019-07-16 9:32 ` Wolfgang Denk
2019-07-16 11:50 ` Siddhesh Poyarekar
2019-07-16 12:40 ` Wolfgang Denk
2019-07-16 12:44 ` Florian Weimer
2019-07-16 14:52 ` Wolfgang Denk
2019-07-16 15:09 ` Florian Weimer
2019-07-16 15:19 ` Andrew Pinski
2019-07-17 14:15 ` Arnd Bergmann [this message]
2019-07-17 14:41 ` Florian Weimer
2019-07-17 16:00 ` Wolfgang Denk
2019-07-17 16:04 ` Florian Weimer
2019-07-17 16:18 ` Lukasz Majewski
2019-07-18 18:53 ` Adhemerval Zanella
2019-07-18 19:13 ` Florian Weimer
2019-07-18 20:31 ` Adhemerval Zanella
2019-07-18 21:20 ` Florian Weimer
2019-07-18 22:32 ` Paul Eggert
2019-07-19 7:21 ` Andreas Schwab
2019-07-19 3:06 ` Rich Felker
2019-07-19 17:44 ` Adhemerval Zanella
2019-07-19 19:03 ` Alistair Francis
2019-07-25 20:40 ` Joseph Myers
2019-07-29 17:47 ` Adhemerval Zanella
2019-07-29 19:58 ` Joseph Myers
2019-07-29 21:00 ` Adhemerval Zanella
2019-07-29 21:08 ` Joseph Myers
2019-07-29 23:12 ` Paul Eggert
2019-07-29 23:30 ` Joseph Myers
2019-07-17 17:50 ` Rich Felker
2019-07-17 21:57 ` Lukasz Majewski
2019-07-17 22:37 ` Rich Felker
2019-07-18 7:20 ` Lukasz Majewski
2019-07-18 13:35 ` Rich Felker
2019-07-18 14:47 ` Rich Felker
2019-07-18 14:49 ` Florian Weimer
2019-07-18 15:46 ` Rich Felker
2019-07-18 16:43 ` Adhemerval Zanella
2019-07-20 4:43 ` Rich Felker
2019-07-25 19:54 ` Joseph Myers
2019-07-26 10:39 ` Lukasz Majewski
2019-07-29 18:55 ` Zack Weinberg
2019-07-29 20:12 ` Joseph Myers
2019-07-30 11:02 ` Lukasz Majewski
2019-07-30 12:24 ` Joseph Myers
2019-07-30 14:04 ` Lukasz Majewski
2019-08-09 7:25 ` Lukasz Majewski
[not found] ` <CAKCAbMhOMQ9yTFpy+OQkDvZPPFf_fFn6oSxjvLTaUwC4jpPRag@mail.gmail.com>
2019-08-09 12:32 ` Fwd: " Zack Weinberg
2019-07-30 19:58 ` Joseph Myers
2019-07-30 20:28 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAK8P3a3mdzYBw_1geg67MpkhpVLkqqqqB3q+rbmgW4gvDsO4UA@mail.gmail.com \
--to=arnd@arndb.de \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=lukma@denx.de \
--cc=wd@denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).