[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1312053234.20898.521.camel@calx>
Date: Sat, 30 Jul 2011 14:13:54 -0500
From: Matt Mackall <mpm@...enic.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: "H. Peter Anvin" <hpa@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Fenghua Yu <fenghua.yu@...el.com>,
Herbert Xu <herbert@...dor.hengli.com.au>,
Theodore Ts'o <tytso@....edu>, Jeff Garzik <jgarzik@...ox.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] random: Add support for architectural random hooks
On Sat, 2011-07-30 at 08:20 -1000, Linus Torvalds wrote:
> On Sat, Jul 30, 2011 at 7:45 AM, Matt Mackall <mpm@...enic.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists