> 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 

That's right.  this is only intended for /dev/random use.  The choice
of names was poor; I'll rename it from "timestamp()" to something more
specific.

>  * 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.

A different interface should be provided for timekeeping.

> 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.

No, I haven't.  i've been meaning to look into options for
high-resolution timekeeping purposes, but that has dramaticaly
different requirements than random timer sampling.

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

/dev/random wants an *efficient, low-overhead* sample of a timer of
indeterminate origin and frequency.  Raw access to the cycle counter
is best for this purpose.  A few dozen or less integer ops would do to
collect the sample and stuff it in a ring buffer for later analysis --
the existing /dev/random driver could do less in the driver interrupt
hook than it does now; having to do a 64-bit fixed-point multiply or
similar crud to scale it into a common timebase, and then undo it,
would make it far more heavyweight than it needs to be.

					- Bill