Yo All! Cross-posted to gpsd-dev and devel@ntpsec.org
Recent glibc (2.34 and up) and recent Linux kernels, allow 64 bit
time_t on 32-bit Linux without much work.
But...
How to get that 2038 compatible time to ntpd and chronyd? That is a
much bigger problem.
Extracted from include/ntpshm.h:
struct shmTime
{
int mode;
volatile int count;
time_t clockTimeStampSec;
int clockTimeStampUSec;
time_t receiveTimeStampSec;
int receiveTimeStampUSec;
int leap; // not leapsecond offset, a notification code
int precision; // log(2) of source jitter
int nsamples; // not used
volatile int valid;
unsigned clockTimeStampNSec; // Unsigned ns timestamps
unsigned receiveTimeStampNSec; // Unsigned ns timestamps
int dummy[8];
};
Note the struct size depends on the size of an int, and the size of time_t.
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).
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?
In hindsight, maybe shmTime should have started with a 1 char version
field,or magic field. But, no such luck.
Options (for 32-bit only):
1. Do nothing, stick with 32-bit time_t. Fail in 2038.
2. Allow 64-bit time_t and let incompatible ntpd fail.
3. Add run time options to gpsd and ntpd to specify time_t size.
4. gpsd and ntpd always use 64-bit time_t going forward. Admin needs
to mix and match.
5. 1st process to open SHM(0) wins, the other process checks the size
to know the contents.
6. Create a new way to pass time from gpsd to ntpd and chronyd.
Also note, chrony sockets have a similar problem:
#define SOCK_MAGIC 0x534f434b
struct sock_sample {
struct timeval tv;
double offset;
int pulse;
int leap; // notify that a leap second is upcoming
int _pad;
int magic; // must be SOCK_MAGIC
};
Where timeval is:
struct timeval {
time_t tv_sec;
suseconds_t tv_usec;
};
```
Since the sample has a magic value, maybe that can be used to detect versions.
This makes my head hurt...
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
pgpAUyyMQ2wlc.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
