adj_systeim()

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> It may be worth checking ntp classic.  We may have lost something in
> that area during all the cleanups.

Nope.  I am absolutely on top of this. Gary's analysis has gone down a
fallback path, not the main one which *does* have ns
precision. Remember all my muttering about the split-code-path problem
when I was trying to explain why TESTFRAME failed?  This is it again.

> Note that there are 3 NANOs: ADJ_NANO, MOD_NANO and STA_NANO.
> 
> My Linux headers say:
> /* xntp 3.4 compatibility names */
> #define MOD_OFFSET      ADJ_OFFSET
> #define MOD_FREQUENCY   ADJ_FREQUENCY
> ...
> 
> Maybe we should fix all our code to use ADJ rather than MOD.

That one is a little messy.

What's actually going on here is that there are two functionally similar
calls, ntp_adjtime() and adjtimex().  The former is sort of semi-portable;
it's Mills's original spec for advanced timekeeping support, more or less,
but it's not standardized and various platform implementations of it have
quirks and extensions.  The most important quirk is that some variants
support nanosecond precision, others only microsecond.

The second one is adjtimex().  This is used under Linux to implement
ntp_adjtime(), but has additional capabilities the former does not.

The MOD_ names are associated with ntp_adjtime(), the ADJ_ names
with adjtimex().  In most cases they're the same bitmasks on the
same structure members. Therefore we actually prefer to use the
MOD_ names, they're more portable to (e.g.) BSD systems.

There's a more detailed explanation in the tour document.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.