Here's a suggestion for a medium-term remedy to the lack of an kernel
API for accessing CPU cycle-counters or high-quality time sources
(which are inherently MD) from MI code:

Code up a MI placebo nanotime() , protected by a defopt #ifdef, which
just scales the microtime() tv_usec results by 1000 to get tv_nsec.

On ports that have cycle counters, and (there) implement microtime(),
provide a high-quality, cycle-counter based nanotime(). define
microtime() in terms of nanotime().   Disable the  placebo.

Once all ports have both microtime() and nanotime(), we can attack the
rest of the kernel, replacing microtime() calls with nanotime(), at
our leisure. (Until we do this, and start tracking time to ns
resolution in the kernel, the nanosecond-resolution timer syscall
might as well be just libc stubs.)

[Yes, I'd like to have an MI kernel API for CPU cycle counters, but
doing that right, in a way that works with SMP and variable clockrates
and ...  needs more thought than i have cycles for now.]

Using nanotime() instead is OK for many purposes, including
/dev/random, until we get CPUs > 1 GHz, which is still a few months
away.



Charles Hannum observes that simply using CPU cycle-counters is
problematica on PCs with with power-managment: automatically diddling
the CPU frequency to save power messes up the time. 

If we can detect hardware that has the feature and has it enabled, an
MD i386 nanotime() could always back off to using the existing time
sources.  I dont know modern x86 hardware well enough to know if this
is feasible, let alone trying to get callbacks when the CPu frequency
changes.  At worst, i386 ports could just use the existing code.

Comments?