Yo Richard! On Fri, 13 Jan 2023 13:43:06 -0600 Richard Laager <rlaa...@wiktel.com> wrote:
> On 1/12/23 19:10, Gary E. Miller via devel wrote:
> > 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.
>
> Here are some thoughts on various options.
>
> I don't know what valid values of "mode" are.
I snipped that part from include/timehint.h:
int mode; /* 0 - if valid set
* use values,
* clear valid
* 1 - if valid set
* if count before and after read of values is equal,
* use values
* clear valid
*/
Clear as mud...
Looks like gpsd only ever sets it to a 1.
NTPsec ntpd/refclock_shm.c (un)helpfully says:
* To add new modes: Extend or union the shmTime-struct. Do not
* extend/shrink size, because otherwise existing implementations
* will specify wrong size of shared memory-segment
Maybe set mode = 2, and use two of the dummy from shmTime:
int dummy[8];
> Could that be used,
> possibly by setting some high bit(s) to indicate a 64-bit time_t and
> a 32-bit int? That would break backwards compatibility, though, as
> old readers would see modes they do not expect.
NTPsec would reject a mode of 2:
default:
shm_stat->status = BAD_MODE;
break;
Maybe keep mode of 1, and dummy[0] could be the top bits of time64_t?
Then old and new clients work until 2038. And new clients after that.
> Do you know if, _in practice_, providers of shmTime are providing
> zeros for the dummy[8] padding?
All I care about is gpsd, and it does zero the padding. Once.
If so, then (subject to agreement
> from the various projects), part of that could be defined as a magic.
> Of course, the problem there is that you need to find dummy[x], which
> can be in different positions depending on the struct size (which is
> the issue at hand).
That is fixable. Just force the existing time_t to be time32_t on
32-bit systems that support 2 types of time_t. The other fields are
"int" and "unsigned".
> One possible solution would be
Too complicated. If dumm[0] is non-zero, take that as the top 32
bits of time64_t. But only on 32-bit dual time_t systems.
Along the way, pull the duplicate shmTime definitions from NTPsec
and gpsd and put them in one system header file.
> > 4. gpsd and ntpd always use 64-bit time_t going forward. Admin
> > needs to mix and match.
>
> I think ntpd (and probably gpsd too) should enable whatever option to
> use 64-bit time_t if the platform supports it. But do we need to
> still support existing 32-bit platforms where time_t is only 32-bit?
> Probably?
Certainly. At least until 2038.
chrony sockets are still a problem...
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
pgpayEnXFDuFq.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
