On 2016-05-25 07:11, 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.
You have a lot of systems with a lot of spare entropy then, or you
unintentionally added a 'u' at the beginning of 'random' and were only
testing on slow systems. Some people (myself included) do seed
/dev/random from hardware RNG's or other daemons (I run both HAVEGE and
rngd), but many people don't, and a majority of embedded systems I've
seen absolutely don't. 48-bits may not seem like much, but if we're
using /dev/random, it has the potential to block indefinitely, and
having that possibility in end-user software is not a good thing.
I would tend to agree with Hugo on this one, we should be using
/dev/urandom, not /dev/random.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
