How the KERNEL_PLL switch kills TESTFRAME

[Hal Murray]

esr at thyrsus.com said:
> The big deal is that a build *with* KERNEL_PLL will generate adjtimex(2)
> events into the capture logs. A build without KERNEL_PLL won't.  Neither
> kind of log will be replayable on the other kind of build. 

I don't have time to help with this now.

I think you should keep working on TESTFRAME.  At worst, we'll end up with a 
Linux only version.  We'll probably learn more.

Part of the problem is that we have a word tangle between my use of "kernel 
PLL" and your use of "KERNEL_PLL".  I was referring to the PLL option in the 
Linux kernel that gets included when you say:
  CONFIG_NTP_PPS=y


I have access to Linux, NetBSD, and FreeBSD.  ntpd runs on all 3 and does 
essentially the same thing.  The key ideas are being able to adjust the clock 
"drift" and being able to slew the clock.

I'll bet other major OSes have similar ideas.  If not, there isn't much ntpd 
can do other than run in SNTP mode and step the clock occasionally.  (That S 
is supposed to be Simple.  An alternative view is Stupid.)

The details on the interface to the kernel may be different for various OSes, 
but the concepts mostly overlap.  I think that's always been one of the rough 
edges.

You said "adjtimex".  There is also ntp_adjtime.  It's available on Linux, 
NetBSD, and FreeBSD.  It's covered in RFC 1589.

The sandbox stuff knows about adjtimex but not ntp_adjtime, so I think we are 
using the wrong API.  There is either a good reason or a bug in the build 
system.


How well does it work if you build to use ntp_adjtime?  Does that do 
something silly like kill using the kernel PPS time stamping?


-- 
These are my opinions.  I hate spam.