Gentlemen,
A thought from out of left field here - Would it be possible to simplify the code by using a tool to partially pre-process the code (e.g. CPPP (http://www.muppetlabs.com/~breadbox/software/cppp.html)), defining in turn HAVE_KERNEL_PPS and HAVE_PPSAPI, and then comparing the resultant "versions"? This _might_ give you the ability to see the 'shape' of the code under the various assumptions about supported kernel features, etc. - *John D. Bell* On 12/03/2017 05:17 PM, Eric S. Raymond via devel wrote: > Hal Murray <[email protected]>: >> [email protected] said: >>> I'm aware. There's a separate HAVE_KERNEL_PPS that conditionalizes the code >>> for the second case. >> I can't find any references to HAVE_KERNEL_PPS >> I assume you mean HAVE_PPSAPI which is only referenced by refclocks > You're right. > >> I screwed up. There are actually 3 things tangled up here. >> >> First: capture pulse timing info. >> Second: adjust "drift" on system clock >> Third: in kernel PLL to adjust drift from PPS pulses >> >> You can't implement the PLL unless you have a drift to adjust and a way to >> capture timing info from PPS pulses. >> >> A lot of what HAVE_KERNEL_PLL was doing was related to the second rather >> than >> the third. > Yes, I got that. > > One of the things that makes this whole area hard to understand is > that the separation (if any) among these three functions you've > described is pretty much entirely undocumented. Nor are they clearly > distinguished from a fourth predicate, which is whether ntp_adjtime() > is present. I have trouble keeping track of all the balls in the air. > > It *is* clear enough that ntp_adjtime() is a prerequisite for any of the > above three things to go on.
_______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
