From owner-svn-src-head@FreeBSD.ORG Wed Apr 1 16:24:24 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id B8C90C0D; Wed, 1 Apr 2015 16:24:24 +0000 (UTC) Date: Wed, 1 Apr 2015 16:24:24 +0000 From: Alexey Dokuchaev To: Mateusz Guzik Subject: Re: svn commit: r280955 - in head/sys: modules/notrandom dev/notrandom Message-ID: <20150401162424.GB85612@FreeBSD.org> References: <20150401113628.GA16649@dft-labs.eu> <20150401114313.GZ64665@FreeBSD.org> <20150401115204.GB16649@dft-labs.eu> <1427897897.82583.62.camel@freebsd.org> <551C0A92.8070507@freebsd.org> <551C0B2A.9060006@freebsd.org> <5A609CED-56E6-4459-8505-58930048AA0D@grondar.org> <20150401154633.GA14631@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150401154633.GA14631@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Benjamin Kaduk , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" , Mark R V Murray X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 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: Wed, 01 Apr 2015 16:24:24 -0000 On Wed, Apr 01, 2015 at 05:46:33PM +0200, Mateusz Guzik wrote: > On Wed, Apr 01, 2015 at 11:36:26AM -0400, Benjamin Kaduk wrote: > > But surely to be non-random we need an equal number of 1 and 0 bits, > > making 15 the clear choice. > > I don't know man. I concur. Consider running FreeBSD to HP48; 15 would max out entire nibble, leading to predictability and risk of overflow attacks. > First off, '7' could not be chosen at random. I'm convinced factors like > amount of CPUs (and their speed), RAM etc. played a huge factor here. > > Now that everything is faster these days, one could ponder returning > '8'. OTOH, eight also fits two elementary units (trits) on trinary machines, which might allow for certain micro-optimizations when you need strong flow of non- random numbers. > We can add an ioctl to control this. > > Opinions? To stay portable, very likely, yes. ./danfe