In message <200006052355.e55Nthl00353@thunk.hamachi.org>Bill Sommerfeld writes
>I just committed changes to the i386 port and to the /dev/random
>driver (sys/dev/rnd.c) to let it use a higher-resolution cycle counter
>in the timestamps it uses for randomness collection.

[request for comments]


Nanosecond-resolution internal kernel timing needs the same infomation
(or very similar).  But this interface looks a bit too trivial 
to use it for that purpose as well:

 * Timing may soon need more than 32 bits,  
 * the low-order bits we want for timing may be zero on some
   implementations of some arches, which means you don't want
   them as input to rnd.

Have you looked at PHK's "timecounter" api in FreeBSD?  That's
designed to support high-resolution timekeeping, tho' parts of it
seemed overly x86-centric the first time I looked at it.

Something like that, plus api to pull out the most-random 32 bits out
of a sample, would be a big improvement.