✘64-bit time_t on glibc 2.34 and up

Sat Jan 14 01:54:12 UTC 2023

Yo Greg!

On Fri, 13 Jan 2023 19:46:15 -0500
Greg Troxel <gdt at lexort.com> wrote:

> "Gary E. Miller" <gem at rellim.com> writes:
> 
> >> Does Linux version syscalls?  In NetBSD, we change the codepoints
> >> when the ABI changes, and there is kernel code to implement the old
> >> codepoint (but no header support) so old binaries still work.  I
> >> think Solaris does this too.  
> >
> > For some definition of "version".  There is one set of syscalls for
> > 32-bit time, including time in file system metadata.  And another
> > for 64 bit time.  And only since late 2021.
> >  
> >> I don't really follow "compile time option".  The size of time_t is
> >> part of the kernel ABI.  
> >
> > Yes.  BOTH sizes of time_t are part of the 32-bit linux kernel ABI.
> >  
> 
> Wow.  So people have to, specially for Linux, version all interfaces
> that use time_t.  That's not just gpsd, but all sorts of things.
> 
> >> Or does the kernel use sys/types.h?  
> >
> > Not relevant.  
> 
> But it has codepoints for syscalls with each flavor.
> 
> >> The headers in sys are semantically part of the kernel, regardless
> >> of how they are sliced up in packaging/maintenance.  
> >
> > Sort of.  sys/tyoes.h is part of musl or glibc.  
> 
> Yes, but it has to match the kernel.  That's why I said semantically
> part of.
> 
> >> shmTime is simply using time_t, so it inherits the definition of
> >> time_t from the compilation environment.  POSIX says that
> >> <sys/time.h> is required to define time_t:
> >> 
> >>   https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_time.h.html
> >>  
> >
> > Yes.  And it does.  Selected by  D_TIME_BITS 64  
> 
> Which magically changes references to syscalls that use time_t, in the
> entire binary, to the new ones?

Uh, once again, no.  No "versioning".  No syscalls are changed.

Every existing syscall that uses 32-bit time_t now has a 64_bit twin.

So old and new binaries just work.

I'm not gonna defend, that is what glibc and Linus negotitated.

> What happens if a library defines D_TIME_BITS 64 and makes syscalls,
> and a program which is unaware of this defines 32 and also makes
> sycalls? Or is the syscall switch per .o because the names are
> #defined?

That can never happen.

> >> > How does ntpd know what size time_t to use? And thus know the
> >> > size of shmTime?  How do we know portably, preserving backwards
> >> > and forwards compatibility?    
> >> 
> >> It builds against the installed headers and just uses time_t.  
> >
> > Yes, but which one?  The 32-bit one, or the 64-bit one?  
> 
> I see.  Well, I see several sane paths:
> 
>   Make a new api in json to work around the Linux approach.  Only use
> it on Linux, with it just serializing the struct.  I really don't
> like this.

We will need a new API for chronyd.  For now, I'm trying to save
existing binaries.

When we get a new chinryd API, I'd like gpsd, ntpd and chonryd to support
it, but that only works going forward, which will take close to a decade
to all migrate.  I need a solution this week.  My shmTime change gets there
right away.  At least for ntpshmmon, ntpd, etc.

>   The entire time community agrees that code will be built 64 if
> that's supported on the build system.

Yeah, and how to get there, while being back compatible with binaries.
My shmTime idead does that.  This week.

>  But then the "linux is one
> ABI" is falling apart and it's going to be a mess as there will be
> old code.

No.  You misunderstand the Linux ABI.  Nothing is falling apart.
Execpt the gpsd to chronyd interace.

> So you have a rule that gpsd/ntpd/chronyd need to all be
> new or all be old. 

And now you know why people hate *BSD.  Liniux does not have "flag
days" that piss everyone off.

>   On Linux, redefine the struct to be int64_t instead of time_t.  add
>   options to gpsd/ntpd/chrony to move to the new way.  After a bit
> take out the option and int64_t is the answer.  After time_t is
> int64_t on all linux systems rename it back to time_t.

And break back compatibility.  Only as a last resort.  Nad last resort
is not required.

> I think the third option is the way to go.  That way each program can
> use 32/64 as it is available but start using the new ABI now.  It will
> interop and as each program is built for 64 it becomes 2038-safe.

Richard liked my idea, you did not discuss it.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20230113/73e69ead/attachment-0001.bin>