DragonflyBSD kernel clock improvements

[Poul-Henning Kamp]

In message <20040124.204514.109171577.imp at bsdimp.com>, "M. Warner Losh" writes:
>In message: <200401242031.i0OKVD8A037265 at apollo.backplane.com>
>            Matthew Dillon <dillon at apollo.backplane.com> writes:
>:     No apic timer.  No acpi timer.  No TSC garbage.  none of that.
>
>Maybe there are better ways to obtain these results.  While not
>directly releated to the nanosleep work, but just another point of
>view.

Most of the uglyness in timecounters comes in for the hardware
independence.

A major design goal was to make it as totally trivial at write the
code necessary for a hardware-gadget to feed timecounters.  I didn't
want to see people who port to new archs run into code where they
have to sit and do fixed-point binary math and worry about accumulative
rounding errors and other weirdness.

I also made the interfaces to the entire timecounter code very
simple so that it could be replaced by an optimized platform specific
implementation.  (For instance on platforms which have a good
calibrated nanosecond counter, s390 comes to mind).

Knowing the precision you need to support up front means that you
don't need the hysteric precision of timecounters.

If Matt is only interested in the PC platform with sufficiently
clued users, he can afford to make the choice of timekeeping a
boot-time or even compile-time fixable just like it is in so many
other UNIX kernels.

A very good place to start is the "nanokernel" from Dave Mills,
and I hope that Matt will consider it, even if I'm listed as
co-author on the paper :-)

It does suffer from a number of gremlins down in the weeniesecond
domain, but I don't think Matt will need to worry about that
but it would give him all the ntpd magic for free.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.