✘64-bit time_t on glibc 2.34 and up

[Gary E. Miller]

Yo Greg!

On Fri, 13 Jan 2023 07:11:49 -0500
Greg Troxel <gdt at lexort.com> wrote:

> "Gary E. Miller" <gem at rellim.com> writes:
> 
> > Recent glibc (2.34 and up) and recent Linux kernels, allow 64 bit
> > time_t on 32-bit Linux without much work.  
> 
> Interesting to hear; I had assumed time_t on Linux was changed long
> ago to int64_t.

Nope, not yet.

> 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.

> > This is no problem for newer musl on 32-bits. An int is 32-bits and
> > time_t is 64.  Assuming all clients use the same version musl.
> >
> > This is a problem for glibc on 32 bits. And int is 32-bits, but
> > time_t is a compile time option (32 or 64 bits).  
> 
> 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.

> Is it specified separately in the kernel sources

No, kernel sources support 32-bit and 64-bit time syscalls at the
same time.

> and in whatever
> sources lead to sys/types.h?

No.  time_t is in syst/time.h, selected by  D_TIME_BITS 64

> Or does the kernel use sys/types.h?

Not relevant.

> 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.

> 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
 
> so I think gpsd has to just assume that's true,

It is true, but has two incompatible truths.

> and if there's a
> system where the kernel size for time_t doesn't match the installed
> header, that just needs to be fixed.

It is handles by using 2 distinct syscall type.  One for 32-bit and
one for 64-bit.

> > 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?

> Of course binaries are not portable across systems with different
> choices for time_t.  Those are different ABIs.

Bout our problem is incompativble SHM and sock on the same ABI.

> > In hindsight, maybe shmTime should have started with a 1 char
> > version field,or magic field.  But, no such luck.  
> 
> Probably time_t should have just been changed to int64_t, no option,
> and syscalls should have been versioned so old binaries work :-)

For some reason Linus does not take out sugggestions...

> > Options (for 32-bit only):
> >
> > 1.  Do nothing, stick with 32-bit time_t. Fail in 2038.  
> 
> How do you "stick with it" if sys/time.h changes on systems configured
> for int64_t?

Bad conclusion, based on incorrect assumption.  The same sys/time.h
can lead to either 32-bit or 64-bit time_t.

> > 2.  Allow 64-bit time_t and let incompatible ntpd fail.  
> 
> How do you "allow"?  By setting -D_TIME_BITS=64

> > 3.  Add run time options to gpsd and ntpd to specify time_t size.  
> 
> That's crazy.

Sometimes you gotta accept crazy.  But I hope not to.

> > 4.  gpsd and ntpd always use 64-bit time_t going forward.  Admin
> > needs to mix and match.  
> 
> How can you use a type different from what the kernel is using?

Easy, when the kernel uses both types at the same time.

> > 5.  1st process to open SHM(0) wins, the other process checks the
> > size to know the contents.  
> 
> That seems messy.

Yup.

> > 6.  Create a new way to pass time from gpsd to ntpd and chronyd.  

Which may have other benefits.

> Indeed, the int in ntpshm should be suseconds_t,

I'm pretty sure this predates suseconds_t.

 but int is ok in
> practice, on ILP32.  On IP16L32, it's not, but we aren't building for
> PDP-11 any more :-)

What is ILP32?  Or IP16L32?

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/6971bf94/attachment.bin>