From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NcFvS-0002Ng-Vo for qemu-devel@nongnu.org; Tue, 02 Feb 2010 05:24:07 -0500 Received: from [199.232.76.173] (port=47550 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NcFvS-0002My-8F for qemu-devel@nongnu.org; Tue, 02 Feb 2010 05:24:06 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NcFvQ-0003Ne-IT for qemu-devel@nongnu.org; Tue, 02 Feb 2010 05:24:06 -0500 Received: from bhuna.collabora.co.uk ([93.93.128.226]:49963) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NcFvQ-0003ME-1l for qemu-devel@nongnu.org; Tue, 02 Feb 2010 05:24:04 -0500 Message-ID: <4B67FD0D.1070900@collabora.co.uk> Date: Tue, 02 Feb 2010 10:23:09 +0000 From: Ian Molton MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/5] socket: Add a reconnect option. References: <1265031265-14717-1-git-send-email-ian.molton@collabora.co.uk> <1265031265-14717-2-git-send-email-ian.molton@collabora.co.uk> <1265031265-14717-3-git-send-email-ian.molton@collabora.co.uk> <4B66F267.3040103@codemonkey.ws> <4B675967.1060503@collabora.co.uk> <4B675BBA.2080907@codemonkey.ws> In-Reply-To: <4B675BBA.2080907@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Luiz Capitulino Anthony Liguori wrote: > I'm all for doing things incrementally but there has to be a big picture > that the incremental bit fits into otherwise you end up with a bunch of > random features that don't work together well. Well, if you just add stuff without ever changing anything that went before, of course. > Honestly, I'd strongly suggest splitting the reconnect logic out of the > series when resubmitting. IMO the RNG stuff is worthless without the reconnect logic. You cant have a machine in a production environment that just stops getting entropy forever when you (say) restart the EGD, perhaps during a package update. Or when someone unplugs the entropy source temporarily or something like that. > I think it's just too hacky with too weak of > a justification. If you really want this functionality, we can discuss > the right approach for doing it but it's gotta be done in a way that's > not introducing a one-off case just for the random number generator. I dont think its a case of 'really want' as much as 'its completely essential' :-) I still think that unless there are any other use cases, theres not much to discuss - The code is already generic to some degree - it notifies users, and its got a configurable delay. What else do we need? I implemented it generically rather than stuff it into the virtio-rng driver *because* I didnt think a dedicated version of it was the right way to go, but without some other use cases, I cant see what good there is in bikeshedding over this? -Ian