From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O51ks-00044y-06 for qemu-devel@nongnu.org; Thu, 22 Apr 2010 15:08:06 -0400 Received: from [140.186.70.92] (port=37026 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O51kp-00043H-FW for qemu-devel@nongnu.org; Thu, 22 Apr 2010 15:08:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O51kn-0001bQ-3N for qemu-devel@nongnu.org; Thu, 22 Apr 2010 15:08:03 -0400 Received: from bhuna.collabora.co.uk ([93.93.128.226]:53610) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O51kj-0001a0-W2 for qemu-devel@nongnu.org; Thu, 22 Apr 2010 15:08:00 -0400 Message-ID: <4BD09E3F.7070605@collabora.co.uk> Date: Thu, 22 Apr 2010 20:06:39 +0100 From: Ian Molton MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG References: <4BB2053C.6000701@collabora.co.uk> <201004031606.26893.paul@codesourcery.com> <4BC482A6.4040504@collabora.co.uk> <201004131632.25820.paul@codesourcery.com> <4BCDC51F.2030205@collabora.co.uk> <20100420161302.GA11723@shareable.org> <4BCE061B.2030506@collabora.co.uk> <20100420205654.GI11723@shareable.org> <4BCE1D3B.7000306@collabora.co.uk> <4BCEAC99.8000206@redhat.com> <20100421094007.GC13114@shareable.org> <4BCEF0B9.2050704@collabora.co.uk> <4BCF03D2.5000307@redhat.com> In-Reply-To: <4BCF03D2.5000307@redhat.com> 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: Gerd Hoffmann Cc: Paul Brook , qemu-devel@nongnu.org Gerd Hoffmann wrote: > Hi, > >> * the SIZE property patch: Msg-Id:<4BB206B9.80501@collabora.co.uk> > > Fine with me. \o/ So should I re-post that patch, or can I count on that being folded into mainline ? >> * the socket reconnect patch: Msg-Id:<4B18055B.1030606@collabora.co.uk> > > Not sure yet. Comment below... > I think it makes sense to have a separate chardev backend for it, so you > can easily hook it up to either virtio-rng or something else, i.e. > define a chardev for the egd connection like this: > > -chardev backend=egd,id=egd,server=$address,$rate-limit-options-here Yes, I like the look of that, at least in principle. > It might make sense to have the reconnect logic in the egd chardev > backend then, thereby obsoleting the socket reconnect patch. Im not sure I agree there... surely there are other things which would benefit from generic socket reconnection support (virtio-rng cant be the only driver that might want to rely on a reliable source of data via a socket in a server-farm type situation?) Do we really want to re-implement reconnection (and reconnection retry anti-flood limiting) in every single backend? Thanks for the review - if we can nail down the reconnection issue, I'll set about a rework of the patchset and resubmit :-) -Ian