Austin S. Hemmelgarn wrote on 2016/05/25 08:39 -0400:
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 (wit
Austin S. Hemmelgarn posted on Wed, 25 May 2016 08:39:08 -0400 as
excerpted:
> I would tend to agree with Hugo on this one, we should be using
> /dev/urandom, not /dev/random.
Add me to the list. I was wondering where urandom was in the discussion
all along, but figured there must be some reaso
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 regener
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 loca
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. Possi
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
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 l
David Sterba wrote on 2016/05/23 14:01 +0200:
The API does not seem right. It's fine to provide functions for full
int/u32/u64 ranges, but in the cases when we know the range from which
we request the random number, it has to be passed as parameter. Not
doing the % by hand.
This makes sense.
The API does not seem right. It's fine to provide functions for full
int/u32/u64 ranges, but in the cases when we know the range from which
we request the random number, it has to be passed as parameter. Not
doing the % by hand.
> +u32 rand_u32(void)
> +{
> + struct timeval tv;
> + unsigne
Btrfs was using normal srand()/rand() pseudo-random number generator
functions.
Although it's mostly fine, but it's quite easy to forget to initialize
the seed.
This patch will introduce new random number generator wrappers:
rand_int(), rand_u8/16/32/64(), and use uniformly distributed
pseudo-ran
10 matches
Mail list logo
