> Here's the inside view from looking at the code: --disable-kernel-PLL turns
> off the use of ntp_adjtime() to slew time, leaving adjustments to be done at
> much coarser granularity by the old-style adjtime(2) call. 

How about we rename it to --disable-ntp_adjtime?

I assume we will get the same effect if ntp_adjtime is not defined in the 
headers.

I stumbled into one case where it is actually interesting.  NetBSD on 
Raspberry Pi has ntp_adjtime in the headers but it's not implemented in the 
kernel.  So a default build of our code crashes.


>> There is a tangle in this area that I don't understand.  When ntpd
>> exits (or crashes), it leaves the previous state in the kernel so anybody
>> running  ntptime will think things are fine.

> What previous state?

The state in the kernel when ntpd last called ntp_adjtime.  The kernel 
doesn't know that ntpd is steering time so it can't tell that a 
stopped/crashed ntpd won't make another call in the future.


[Kernel bug - not returning STA_NANO when status is UNSYNC.]
> Yes, and it makes a fix difficult.  Do you have any recommended action?

Just add a comment to that area.  It's probably worth nuking the first time 
setup call just to simplify things.  The first call will run in micro mode.  
That will update the nano flag so the second call will work as expected.


-- 
These are my opinions.  I hate spam.



_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Reply via email to