Messages in this thread |  | | | Subject | Re: [PATCH 1/2] random: Add support for architectural random hooks | | From | Matt Mackall <> | | Date | Sat, 30 Jul 2011 12:45:59 -0500 |
| |
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.
|  |