From owner-svn-src-head@FreeBSD.ORG Sat Jan 28 08:48:38 2012 Return-Path: Delivered-To: svn-src-head@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 053C31065670; Sat, 28 Jan 2012 08:48:38 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 7A9908FC08; Sat, 28 Jan 2012 08:48:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vniz.net (8.14.5/8.14.5) with ESMTP id q0S8mYL6014217; Sat, 28 Jan 2012 12:48:35 +0400 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by localhost (8.14.5/8.14.5/Submit) id q0S8mYfM014216; Sat, 28 Jan 2012 12:48:34 +0400 (MSK) (envelope-from ache) Date: Sat, 28 Jan 2012 12:48:33 +0400 From: Andrey Chernov To: Bruce Evans Message-ID: <20120128084832.GA13860@vniz.net> Mail-Followup-To: Andrey Chernov , Bruce Evans , John Baldwin , Mark Murray , David Schultz , src-committers@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, svn-src-head@FreeBSD.ORG References: <20120126143819.GA88677@vniz.net> <20120126155626.GA92229@vniz.net> <201201261132.38320.jhb@freebsd.org> <20120126165521.GA92622@vniz.net> <20120126175021.GA93016@vniz.net> <20120127201855.K1604@besplex.bde.org> <20120128043118.GA12241@vniz.net> <20120128045854.GA12556@vniz.net> <20120128180310.F1114@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120128180310.F1114@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: src-committers@FreeBSD.ORG, John Baldwin , svn-src-all@FreeBSD.ORG, svn-src-head@FreeBSD.ORG, David Schultz , Mark Murray Subject: Re: svn commit: r230230 - head/sys/dev/random X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 08:48:38 -0000 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/