How the KERNEL_PLL switch kills TESTFRAME

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> 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.

Alas, *I* think that pouring more effort into TESTFRAME looks at this point
like a losing proposition.  More visibility into what ntpd is doing we
can get with conventional logging.  Since we can't make replay work portably,
the capture side loses its point

I hope we'll get to re-use this work someday, but in order to do that
we need to remove the blocker -- by, for example, getting the userspace
PLL to converge fast enough that we can simply stop using adjtimex(2)

> 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 see from replies that you and Gary are arguing about this.  I don't need
or want to be in that argument.  I have other things I need to do, like
landing Daniel's rewrite of the protocol machine.

My request for you two is this: Work out some terminology that you can
agree on, inventing new terms if required (they can be "Fred" and
"Barney" for all I care).  Apply it to the tour document. Then use it
so nobody gets confused, and I will too.

(This is a major reason why I write things like the tour document in
the first place - to learn when people are talking past each other
and give them a way to stop doing that.)
 
> 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.

Of course they do.  I can figure that much out even with my relatively
poor domain knowledge.

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

I'm aware of it.  It's described in the new section.
 
> 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.

There's a good reason.  Under Linux, ntp_adjtime(2) is implemented as a thin
userspace wrapper around adjtimex(2).  The seccomp logic doesn't have to know
about the former.

> 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?

No.  Gary has done this and reported on it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>