How the KERNEL_PLL switch kills TESTFRAME
Eric S. Raymond
esr at thyrsus.com
Wed Sep 28 20:21:14 UTC 2016
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
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
> > (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...
Size: 811 bytes
Desc: not available
More information about the devel