Adam Glass says:
> I really don't think random number functionality should appear in the
> kernel.  I don't see any reason why this should be a kernel service.

Only because the kernel has access to far more variables that are nice
and timing dependant. Trying to do PRNGs from userland on Unix often
produces nasty surprises -- you find out that odd timing interactions
between several programs in the run queue produce interesting
regularities in your output and things of that sort. Also, these
things are actually lower overhead in the kernel -- you can ask the
current value of the clock as often as you want without system calls.

And, as I noted, there are several true random number generators on
the market available, and if you had one you could just drop it in
place of the software driver.

That said, I don't think this is *crucial*, just a neat hack.

> fyi: the driver you refer to is GPLed to my knowledge and thus would
> never appear in the kernel as distributed from us.

I suspect that Ted could be convinced to release a Berkeley copyright
version -- as the author he can do things like that -- or perhaps we
could simply write a new one if he wouldn't and/or if it turned out
not to be portable. I'll have to write Yet Another PRNG for my code
(and in fact I need several because I need a non-secure sequence of
pseudorandoms with a very long period for initialization vectors on
packets) and maybe I should put my money were my mouth is and produce
this at the same time.

Understand, I won't push this issue -- its not something we absolutely
*need*, but add my voice to those who think this is not an
unreasonable hack to ask for -- although only the cryptoweenies like
myself usually ask for 'em...

Perry