How the KERNEL_PLL switch kills TESTFRAME

[Eric S. Raymond]

Gary E. Miller <gem at rellim.com>:
> > 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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160929/5f88f274/attachment.bin>