Yo Greg! On Fri, 13 Jan 2023 07:11:49 -0500 Greg Troxel <g...@lexort.com> wrote:
> "Gary E. Miller" <g...@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 g...@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
pgpbmhQEs6pDt.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
