Should the HAVE_KERNEL_PLL conditional be abolished?

John D. Bell jdb at
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
(, 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>:
>> esr at 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...
URL: <>

More information about the devel mailing list