NetBSD 6.1.5 doesn't have ldexpl in math.h

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> So if you are saying that if the kernel has slew mode it has to call it 
> ntp_adjtime or adjtime, that's OK, I guess, but not part of POSIX.

That is correct.  I have researched this extensively, and while there are
still some places my grasp of the code is incomplete this is not one of them.
>From  devel/tour.txt:

    == System call interface and the PLL ==

    All of ntpd's clock management is done through four system calls:
    clock_gettime(2), clock_settime(2), and either ntp_adjtime(2) or the
    older BSD adjtime(2) call.  For ntp_adjtime(), ntpd actually uses a
    thin wrapper that hides the difference between systems with
    nanosecond-precision and those with only microsecond precision;
    internally, ntpd does all its calculations with nanosecond precision.

    The clock_gettime(2) and clock_settime(2) calls are standardized in
    POSIX; ntp_adjtime(2) is not, exhibiting some variability in
    behavior across platforms (in particular as to whether it supports
    nanosecond or microsecond precision).

    Where adjtimex(2) exists (notably under Linux), both ntp_adjtime()
    and adjtime() are implemented as library wrappers around it.  The
    need to implement adjtime() is why the Linux version of struct timex
    has a (non-portable) 'time' member;

    There is some confusion abroad about this interface because it has
    left a trail of abandoned experiments behind it.

    Older BSD systems read the clock using gettimeofday(2) 
    (in POSIX but deprecated) and set it using settimeofday(2),
    which was never standardized. Neither of these calls are still
    used in NTPsec, though the equally ancient BSD adjtime(2) call
    is, on systems without kernel PLL support.

    Also, glibc (and possibly other C libraries) implement two other
    related calls, ntp_gettime(3) and ntp_gettimex(3). These are not used
    by the NTP suite itself (except that the ntptime test program attempts
    to exercise ntp_gettime(3)), but rather are intended for time-using
    applications that also want an estimate of clock error and the
    leap-second offset.  Neither has been standardized by POSIX, and they
    have not achieved wide use in applications.

    Both ntp_gettime(3) and ntp_gettimex(3) can be implemented as wrappers
    around ntp_adjtime(2)/adjtimex(2).  Thus, on a Linux system, the
    library ntp_gettime(3) call could conceivably go through two levels 
    of indirection, being implemented in terms of ntp_adjtime(2) which
    is in turn implemented by adjtimex(2).

    Unhelpfully, the non-POSIX calls in the above assortment are very
    poorly documented.

    The roles of clock_gettime(2) and clock_settime(2) are simple.
    They're used for reading and setting ("stepping", in NTP jargon) the
    system clock.  Stepping is avoided whenever possible because it
    introduces discontinuities that may confuse applications.  Stepping is
    usually done only at ntpd startup (which is typically at boot time)
    and only when the skew between system and NTP time is relatively
    large.

    The sync algorithm prefers slewing to stepping.  Slewing speeds up or
    slows down the clock by a very small amount that will, after a
    relatively short time, sync the clock to NTP time.  The advantage of
    this method is that it doesn't introduce discontinuities that
    applications might notice. The slewing variations in clock speed are so
    small that they're generally invisible even to soft-realtime
    applications.

    The call ntp_adjtime(2) is for clock slewing; NTPsec never calls
    adjtimex(2) directly, but it may be used to implement
    ntp_adjtime(2). ntp_adjtime(2)/adjtimex(2) uses a kernel interface to
    do its work, using a control technique called a PLL/FLL (phase-locked
    loop/frequency-locked loop) to do it.

    The older BSD adjtime(2) can be used for slewing as well, but doesn't
    assume a kernel-level PLL is available.  Some platforms, like OpenBSD
    and Mac OS X, use only this call because they lack ntp_adjtime(2).
    Without the PLL calls, convergence to good time is observably a lot
    slower and tracking will accordingly be less reliable.

> Has anybody tested our code with MUSL?

I have a dim memory of someone reporting good results with it, 
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.