Should the HAVE_KERNEL_PLL conditional be abolished?
John D. Bell
jdb at systemsartisans.com
Mon Dec 4 01:23:27 UTC 2017
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
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 <hmurray at megapathdsl.net>:
>> esr at thyrsus.com 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel