Re: ✘64-bit time_t on glibc 2.34 and up

[Greg Troxel]

"Gary E. Miller" <gem@rellim.com> writes:

> Yo Greg!
>
> On Fri, 13 Jan 2023 20:20:48 -0500
> Greg Troxel <gdt@lexort.com> wrote:
>
>> Greg Troxel <gdt@lexort.com> writes:
>> 
>> I just had a realization.   What Linux is doing is more or less:
>> 
>>   Do the same thing that BSDs did: change time_t to in64_t and change
>>   the syscall codepoints.  (Except you have to define something.)
>
> No, not change time_t.  Add an incompatible alias to time_t.

When you compile with -D _TIME_SIZE_BITS=64, doesn't it cause time_t to
be a different type for that compilation?

>>   Unlike the BSD approach, also support -- even on post-change systems
>>   -- compiling code that uses int for time_t, and using the old
>>   codepoints.
>
> Uh, lost me?  I thought BSD had a flag day and just changed all
> time_t to int64_t and broke all back compat?

Not quite.

  time_t was changed to int64_t

  all syscalls that have time_t in the ABI got a new number

  compat syscalls were added that use the old ABI, using the old
  numbers.

Thus:

  newly built programs see time_t as int64_t and use the new syscalls

  binaries from Before, which have code to use time_t as 32 bits, use
  the compat syscalls and thus continue to work (until 2038).  For
  example you can boot a NetBSD 6 kernel on a system with 5 userland and
  packages built under 5 and it all works fine.

  nothing was done about ABIs like the gpsd/ntpd/chrony ones.  So you
  need all of those programs consistently from before or after.

  Aside from programs that have these inter-program ABI with time_t,
  everything is ok, even with a mix of old and new binaries.

>> We could just treat the Linux approach like the BSD one and try ignore
>> the ability to compile in "time_t is int" mode.
>
> Sadly, Linux did not do that.  I doubt they twill change course now.

But we can choose to always define _TIME_SIZE_BITS=64 when building on
Linux.  That's what I meant by ignore the ability to compile in the old
way: just don't.

>>  If all of
>> gpsd/chronyd/ntpsec:
>> 
>>   By default (on Linux only) check if the flag to get "time_t is
>>   int64_t" is available and use it
>
> Which means old and new can't mix.  Not an option.

I think it's a perfectly reasonable option.  Packaging systems
(distributions) are going to have to deal with this in general.

>> We do know all this code works fine when
>> built in a "time_t is int64_t" environemnt from the last 9 years of
>> use on NetBSD.
>
> NetBSD just blew off binary compatibility.  Linux does not do that.

Not at all, see above.   Binary compat is excellent in this case.  You
just can't build for the old ABI on new systems.  (I have no memory of
anyone asking to do this.)

>> then way, we end up just using the time_t is int64_t, with no options
>> and no grossness, after some number of years.
>
> Everything is so simple in BSD land, where you can tell your users
> to do as you say.

That's unfair, and this discussion has crossed into no longer useful.

I have no memory of pain from the transition.  People basically upgraded
packages from ones built for 5 to ones built for 6, just as they
typically do when upgrading and went from all old to all new, and had no
trouble.  I know of a system with NetBSD 7 kernel and userland and
packages built from and while it's overdue for updating, it is havig no
time_t issues.

The problem here is because various distributions will change to the new
kernel at various times but there is an idea that there is a single
Linux ABI.   Still, if the syscalls that programs see when building with
_TIME_SIZE_BITS=64 have new codepoints:

  old and new binaries should run on new kernels

  only old binaries will run on old kernels

  programs with non-syscall ABIs with time_t need to either

    be consistently old or new

    do something kludgy

I don't see it as a problem to expect 3 programs to be all old or all
new.

But as long as the accomodations for this are all #idef linux, I don't
really care.