Context: The struct ffclock_estimate member of struct fftimehands holds
the parameters maintained by the FFclock daemon for the native FFclock
(natFFC), in a form suitable for kernel fixed point arithmetic.
This commit modifies struct ffclock_estimate, constituting a change in
the kernel<-->daemon API reflected in bumping ffclock_version (defined
in kern_ffclock.c) from 2 to 3. The structure is now 7*64 bits, or 56
bytes.
A new member secs_to_nextupdate is defined to enable FFclock advancement
in ffclock_windup to be aware of when daemon updates are stale.
This fixes two issues:
i) (ffclock_updated <= 0 branch): when assessing if the FFclock should
adopt an unsynchronized state, previously only the age of the last update was taken into account, without any comparison against what is normal/expected.
ii) (ffclock_updated > 0 branch): previously an attempt to estimate the
value of secs_to_nextupdate was assigned to "polling". This inference was costly and could fail in several ways. It is better to simply allow the daemon, who owns this parameter, to supply its value. It is efficient to supply the values measured in seconds, but it is also necessary to convert it into counter units, however this is a low cost operation.
Other changes concern the three leap second related members:
leapsec_next: renamed from leapsec to better describe its role leapsec_total: storage has been reduced from 16 to 8 bits (still very generous) to make room for secs_to_nextupdate. leapsec_expected: renamed from leapsec_next to better describe its role
Leapsec related comments have also been improved throughout.
bug: the test (ffc > cest.leapsec_next) would erroneously succeed
whenever leapsec_next was unset (which is almost all the time). Corrected tests are in ffclock_abstime and ffclock_getsnapshot.
Corresponding updates are made to the compat syscall code in
freebsd32{.h,_misc.c}. The new compat structure has 52 bytes as before,
but without the need for padding.
Bug: in each of freebsd32_ffclock_{set,get}estimate, the (orig,dest)
argument order for calls to the CP macro was incorrect.