svn commit: r230230 - head/sys/dev/random

[Andrey Chernov]

On Sat, Jan 28, 2012 at 06:47:50PM +1100, Bruce Evans wrote:
> > --- sys/libkern.h.old	2012-01-16 07:15:12.000000000 +0400
> > +++ sys/libkern.h	2012-01-28 08:49:19.000000000 +0400
> > @@ -70,6 +70,11 @@ static __inline int abs(int a) { return
> > static __inline long labs(long a) { return (a < 0 ? -a : a); }
> > static __inline quad_t qabs(quad_t a) { return (a < 0 ? -a : a); }
> >
> > +#define	ARC4_ENTR_NONE	0	/* Don't have entropy yet. */
> > +#define	ARC4_ENTR_HAVE	1	/* Have entropy. */
> > +#define	ARC4_ENTR_SEED	2	/* Reseeding. */
> > +extern int arc4rand_iniseed_state;
> > +
> > /* Prototypes for non-quad routines. */
> > struct malloc_type;
> > uint32_t arc4random(void);
> 
> ... I will also ask for data and macros to be sorted into the data an
> macro sections and not unsorted in between the first set of inlines
> and the prototypes.  (Whether the macros should be all in a macro
> section or near the variables or prototypes that they are for is
> unclear, especially since the current organization for this in this
> file is random.)
> 
> This file was last nearly sorted in FreeBSD-2.1.  Now its organization
> is partly to put macros and data together with inline functions that
> use them.  This gives lots of subsections which are not clearly delimited
> and is not used in the prototype section, where it would split up that
> section too much.

It is unclear for me what exact place(s) you suggest for those 
defines/extern now, keeping in mind that I don't want to reorganize old 
code at this moment, so the patch should be at the minimum level.

> > About atomic ops: arc4rand calls are protected with mutex and yarrow 
> > calls are protected, but they can works concurrently wich each 
> > other. So, if we have atomic ops, why not to use them to close one time 
> > window too?
> 
> Hmm, it's tricky code either way.  I use similar cmpsets in sio, and
> also need a loop to synchronize the final state change.  But when the
> state is seen to be final, atomic ops are not needed to check that it
> doesn't change (or to see that it is final), since it won't change again.
> This gives a tiny optimization that would be larger here.  This is mostly

I can try to eliminate after-done repeating of those cmpsets using plain 
static variables in yarrow and arc4rand, but this code should be run under 
mutex. For arc4rand at least it means that yet one cmpset (non-repeated, 
now under mutext) should be added. Is such complications worth something?
Are cmpsets overkills or require heavy processor resources?

-- 
http://ache.vniz.net/