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 Sat, 2011-07-30 at 08:20 -1000, Linus Torvalds wrote:
> On Sat, Jul 30, 2011 at 7:45 AM, Matt Mackall <mpm@selenic.com> wrote:
> >
> > Did you even look at these patches?
>
> Umm. My exact point about the email was that we should if anything
> change Peter's patch *away* from some kind of abstracted driver
> interface.

Well then rather than saying my NAK doesn't matter, you should say you
also NAK it.

> But that was what you were arguing for, and that was what I
> was dismissing.

Is there a reason you think making RDRAND available to userspace as a
HWRNG is a bad idea? Is there a reason it's not the most obviously
correct, least controversial first step to supporting this hardware?

No, there's not. Which is why I asked Peter to do this weeks ago.

> So when you argue for not taking the patches because you want a
> generic interface, I tell you that the argument is bogus.

It will only be bogus when Peter shows up with a patch that doesn't
touch /dev/urandom, which IS a generic interface.

> Now, if you now argue that we should make it closer, and not take
> Peter's patches for *that* reason, then I'd be in whole-hearted
> agreement with you.

There are two sets of possible consumers here, in-kernel and userspace.
Peter's patches are aimed squarely at the latter but you seem to be
talking exclusively about in-kernel users.

This is a lot like RDTSC. Sure, it makes sense to have an in-kernel
inline for this. I've even suggested a name. But when it comes to
gettimeofday(), we're going to insist on using a clocksource and we're
going to insist that it meets all the guarantees that gettimeofday()
normally makes.

--
Mathematics is the supreme nostalgia of our time.




\
 
 \ /
  Last update: 2011-07-30 21:17    [W:2.155 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site