All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hugo Mills <hugo@carfax.org.uk>
To: dsterba@suse.cz, Qu Wenruo <quwenruo@cn.fujitsu.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs-progs: utils: use better wrappered random generator
Date: Wed, 25 May 2016 11:20:13 +0000	[thread overview]
Message-ID: <20160525112013.GK16712@carfax.org.uk> (raw)
In-Reply-To: <20160525111138.GP29147@suse.cz>

[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]

On Wed, May 25, 2016 at 01:11:38PM +0200, David Sterba wrote:
> On Wed, May 25, 2016 at 08:33:45AM +0800, Qu Wenruo wrote:
> > 
> > 
> > David Sterba wrote on 2016/05/24 11:51 +0200:
> > > On Tue, May 24, 2016 at 08:31:01AM +0800, Qu Wenruo wrote:
> > >>> This could be made static (with thread local storage) so the state does
> > >>> not get regenerated all the time. Possibly it could be initialize from
> > >>> some true random source, not time or pid.
> > >>
> > >> I also considered true random source like /dev/random, but since it's
> > >> possible to wait for entropy pool, it would be quite slow and confusing
> > >> for users.
> > >
> > > How would it be confusing? We'll once seed the random generator from
> > > /dev/random, reading 3 * 16bit for the nrand generator context.
> > 
> > Reading from /dev/random may sleep, until the entropy pool is filled.
> 
> I know, but does this apply in our case? We're going to get just a few
> bytes to seed.  I want to avoid inventing own random number generation
> schemes, so we'll use a standard random number source or API.
> 
> /dev/random gives about 1-2MB/s of random data on several machines I've
> tried.

   Just use /dev/urandom?

   See, e.g. http://www.2uo.de/myths-about-urandom/

   Hugo.

-- 
Hugo Mills             | Putting U back in Honor, Valor, and Trth.
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2016-05-25 11:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-23  3:10 [PATCH] btrfs-progs: utils: use better wrappered random generator Qu Wenruo
2016-05-23 12:01 ` David Sterba
2016-05-24  0:31   ` Qu Wenruo
2016-05-24  9:51     ` David Sterba
2016-05-25  0:33       ` Qu Wenruo
2016-05-25 11:11         ` David Sterba
2016-05-25 11:20           ` Hugo Mills [this message]
2016-05-25 12:39           ` Austin S. Hemmelgarn
2016-05-25 19:19             ` Duncan
2016-05-26  0:27             ` Qu Wenruo

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=20160525112013.GK16712@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo@cn.fujitsu.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.