> 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
