How the KERNEL_PLL switch kills TESTFRAME

[Eric S. Raymond]

Mark: Heads up! TESTFRAME is probably almost pointless now, or at
least we can't count on it being fit for its original use until we
solve the slow-convergence problem well enough to dispense with the
KERNEL_PLL code.

Gary E. Miller <gem at rellim.com>:
> Hal Murray:
> > I don't see the problem.  TESTRAME is testing ntpd, not the kernel.
> > It records everything that goes in/out of ntpd.  Replay should do the
> > same even if run on a different sysem/OS/architecture.
> 
> Except an ntpd built on a system with no kernel PLL will not even compile
> in that code.  At least as now coded.  Could be fixed.

That's not the big deal.

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.

The original goal for TESTFRAME was to be able to collect a bunch
of representative capture logs and reply them on every waf check,
and along with the unit tests at the end of the build.

The problem is that KERNEL_PLL as a build *variable* makes capture
logs non-portable, which means we can't have a single set of standard
tests.  I have known this was going to be a problem for a long time -
I've mumbled about it once or twice.  I kept hoping I'd find a
solution.  I didn't.

This is why I jumped with glad cries of glee on Hal's suggestion that
the KERNEL_PLL code might be obsolete and dispensable.  If we could
drop that facility this blocker goes away.

Well, Gary just measured KERNEL_PPL and non-KERNEL_PLL builds side by
side.  We can't drop it.  Convergence gets *really* slow without it.

TESTFRAME with this constraint would not be *entirely* useless.
Daniel could use it for sploit testing.  But it can no longer
be at the center of our test strategy, at least not until we
solve the convergence-speed problem well enough to discard
KERNEL_PLL entirely.

> > (There might be some differences between 32/64 bit systems.)
> 
> I would doubt it.

Right, I don't think so either.  I think I know where the 32-vs.-64-bit
issues are in this codebase and none of them are near that.
-- 
		<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/20160928/5ef9b6ab/attachment.bin>