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.Received on Sun Jan 25 2004 - 00:10:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:39 UTC