Re: Accelerating Y2038 glibc fixes

[Arnd Bergmann <arnd at arndb dot 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