[lkml]   [2003]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] frandom - fast random generator module
In article <>, Jeff Garzik  <> wrote:

| In this case, there is no such requirement. More below.

If the result is used for crypto that is a requirement, as noted in the
original post. See below. And if it's in a shared library it's subject
to various other attempts at control or duplication of results.
| > But it's really a matter of taste. That's why I bring up the subject here.
| Processors are trending towards putting RNG on the CPU. VIA won't be
| the last, I predict. When generating random bits is a single
| instruction, "xstore", userspace applications _should_ be directly using
| this. It should not be in-kernel. And similarly, if there is no
| requirement that the kernel's entropy pool is used, the userspace
| application _should_ be where the implementation lives.

If you are running multiple threads you may really want some independent
random numbers. Looking at this, I believe that if I open the device and
then various threads read blocks from the device, each will get
independent random numbers.

Take this as "there are benefits to having this in the kernel" and not
"this really should be in the kernel." A contribution to the discussion.

What I don't hear is results from testing, from doing this as a
procedure, etc.
bill davidsen <>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:58    [W:2.107 / U:12.324 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site