lkml.org 
[lkml]   [2011]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/2] random: Add support for architectural random hooks
From
Date
On Fri, 2011-07-29 at 23:20 -0700, Linus Torvalds wrote:
> On Fri, Jul 29, 2011 at 2:16 PM, Matt Mackall <mpm@selenic.com> wrote:
> >
> > I have already NAKed this approach in no uncertain terms.
>
> Doesn't matter.

Good to know, feel free to drop me from MAINTAINERS.

> Talking about "standard hardware random number drivers" is just crazy
> talk, when the instruction is a single instruction that takes tens of
> nanoseconds to run. Any driver overhead would be just crazy, and no
> user would ever want that anyway.

Did you even look at these patches?

Here's Peter's interface:

+ ssize_t (*get_entropy_krnl)(void *buf, size_t nbytes);

Here's the hwrng interface:

int (*read)(struct hwrng *rng, void *data, size_t max, bool wait);

The overhead on the kernel side for an "architectural random hook" and a
bog-standard HWRNG is basically the same. Here's a buffer, put N bytes
in it.

But then, the bulk of this patch is actually putting in a fast path to
pass this off to user space through /dev/urandom.

So here you are yammering on about "any driver overhead would be just
crazy" when the whole point of these patches is in fact CHARACTER
DRIVERS. We could already have a HWRNG interface that's just as fast in
the time we've spent debating this.

If you want to add a function get_fast_random_bytes() that turns into
inline assembly on Intel (and Via Padlock and whatever else shows up)
and falls back to get_random_bytes, great. That has nothing to do with
these patches.

--
Mathematics is the supreme nostalgia of our time.




\
 
 \ /
  Last update: 2011-07-30 19:49    [W:0.066 / U:13.716 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site