Subject: Re: new MI/MD interface for rnd(4)
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Bill Sommerfeld <email@example.com>
Date: 06/05/2000 21:15:08
> 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
> * 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.