Should the HAVE_KERNEL_PLL conditional be abolished?

[John D. Bell]

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 <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...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20171203/0646a7a2/attachment.html>