Gary E. Miller <[email protected]>: > > Which I find strange. Preferred for portability, maybe, but > > adjtimex() is strictly more powerful. > > really? How do you get that from this text: > > ntp_adjtime () > The ntp_adjtime() library function (described in the NTP "Kernel > Appli‐ cation Program API", KAPI) is a more portable interface > for performing the same task as adjtimex(). Other than the > following points, it is identical to adjtime(): > > * The constants used in modes are prefixed with "MOD_" rather > than "ADJ_", and have the same suffixes (thus, MOD_OFFSET, > MOD_FREQUENCY, and so on), other than the exceptions noted in the > following points. > > * MOD_CLKA is the synonym for ADJ_OFFSET_SINGLESHOT. > > * MOD_CLKB is the synonym for ADJ_TICK. > > * The is no synonym for ADJ_OFFSET_SS_READ, which is not > described in the KAPI.
Look at the last paragraph. There's a capability adjtimex has that
isn't in ntp_adjtime().
The documentation is vague, on the details, so I am too. But I think there
are (other) things you can do to the kernel PLL with adjtimex(2) that you can't
do with ntp_adjtime(2). There are certainly more reporting fields.
Perhaps we don't use those capabilities. Feel free to replace calls and
smoke-test the resultl I certainly wouldn't be unhappy if we could sever
our dependency on that call.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
