From: "H. Peter Anvin" <hpa@zytor.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Deepak Saxena <dsaxena@plexity.net>,
Jeff Garzik <jgarzik@pobox.com>, Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, tony@atomide.com
Subject: Re: [patch 0/5] HW RNG cleanup & new drivers
Date: Sun, 30 Oct 2005 15:04:40 -0800 [thread overview]
Message-ID: <43655188.3000808@zytor.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0510301433070.27915@g5.osdl.org>
Linus Torvalds wrote:
>
> On Sun, 30 Oct 2005, Deepak Saxena wrote:
>
>>I think moving it to user space will add more complexity for
>>the case where the HW unit is shared with an in in-kernel driver.
>
>
> Moving it to user space is just generally stupid.
>
> Often, the random stuff comes from chipsets, not the CPU itself. Not
> user-accessible at all, and even if it were, it would be a bad idea to
> have user space do things the kernel does normally ("what northbridge do I
> have").
>
> There may be use for a user-level library that handles the native CPU
> instructions for high performance, but that in no way negates the reason
> why /dev/random and friends exist in the first place.
>
We're not talking about /dev/random, we're talking about /dev/hw_random
which is read by rndg and then fed by userspace back into /dev/[u]random.
Clearly, there are cases (e.g. VIA) where rndg or a library called from
rngd could just as easily have done the extraction in userspace, and for
that, it makes no sense to force it to do it in the kernel. For some,
it could be done either way, and for others a kernel driver is clearly
needed. Integrating them all into /dev/hw_random was probably a
mistake, though.
-hpa
prev parent reply other threads:[~2005-10-30 23:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-29 19:12 [patch 0/5] HW RNG cleanup & new drivers Deepak Saxena
2005-10-29 19:12 ` [patch 1/5] Remove existing hw_random implementation Deepak Saxena
2005-10-29 19:12 ` [patch 2/5] Core HW RNG support Deepak Saxena
2002-01-01 5:46 ` Pavel Machek
2005-10-29 19:12 ` [patch 3/5] Intel IXP4xx driver Deepak Saxena
2005-10-29 19:12 ` [patch 4/5] x86 driver Deepak Saxena
2005-10-29 19:12 ` [patch 5/5] TI OMAP driver Deepak Saxena
2005-10-29 22:09 ` [patch 0/5] HW RNG cleanup & new drivers Jeff Garzik
2005-10-29 22:25 ` Linus Torvalds
2005-10-29 22:33 ` Jeff Garzik
2005-10-30 19:58 ` Deepak Saxena
2005-10-30 0:23 ` Gene Heskett
2005-10-30 14:31 ` Alistair John Strachan
2005-10-30 18:08 ` Kalin KOZHUHAROV
2005-10-30 19:35 ` Folkert van Heusden
2005-10-30 20:02 ` Deepak Saxena
2005-10-30 22:35 ` Linus Torvalds
2005-10-30 23:04 ` H. Peter Anvin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43655188.3000808@zytor.com \
--to=hpa@zytor.com \
--cc=akpm@osdl.org \
--cc=dsaxena@plexity.net \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tony@atomide.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox