/dev/io , /dev/mem : only used by Xorg?

Loren M. Lang lorenl at alzatex.com
Tue Mar 1 20:53:45 PST 2005


On Mon, Feb 28, 2005 at 12:13:08PM -0800, Kris Kennaway wrote:
> On Mon, Feb 28, 2005 at 04:58:02AM -0800, Ted Mittelstaedt wrote:
> 
> > Yes - there's some random testing suites on the Internet, find a
> > few and compile them. (ENT for example) Run them repeatedly and see what
> > happens.
> > 
> > Part of the problem is that BY DEFAULT the random device DOES NOT
> > look at interrupts.  See the man page for rndcontrol.  Presumably
> > the system admin of the system knows this and looks at his dmesg
> > output to see which irq's are assigned to network cards and hard
> > disks (which are fairly good sources of randomness) and sets the
> > random device to use these.  In practice this isn't something mentioned
> > in the install docs so it is very unlikely many people know.
> > 
> > Another strange thing is that /dev/random should block when it
> > runs out of entropy - it doesen't seem to do so, however.  And the
> > device doesen't seem to gain entropy that quickly.
> 
> No, it should not block because it's not defined to block and that
> would be a bad interface anyway.  It does return as many bytes as it
> can, and if the application wants more entropy than given then it can
> either poll, or fall back to alternative mechanisms as it sees fit
> (blocking would prevent this).

I would expect it to behave like other descriptors where by default it
should block unless the O_NONBLOCK flag it set in which it would return
immediately with an error message EAGAIN.  Then an app designer can
choose which he wants.  But /dev/random should not just always return
some data even if there's not enough entropy in the pool.  That's
/dev/urandom's job.

> 
> Anyway, all your concerns are moot for 5.x.
> 
> Kris


-- 
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.

Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc
Fingerprint: CEE1 AAE2 F66C 59B5 34CA  C415 6D35 E847 0118 A3D2
 


More information about the freebsd-questions mailing list