From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O5JXf-0008UC-HK for qemu-devel@nongnu.org; Fri, 23 Apr 2010 10:07:39 -0400 Received: from [140.186.70.92] (port=40204 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O5JXd-0008U3-Gh for qemu-devel@nongnu.org; Fri, 23 Apr 2010 10:07:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O5JXb-0008Do-BP for qemu-devel@nongnu.org; Fri, 23 Apr 2010 10:07:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3536) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O5JXb-0008Df-3P for qemu-devel@nongnu.org; Fri, 23 Apr 2010 10:07:35 -0400 Message-ID: <4BD1A998.2020500@redhat.com> Date: Fri, 23 Apr 2010 16:07:20 +0200 From: Gerd Hoffmann 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> <4BD09E3F.7070605@collabora.co.uk> <4BD15A0D.6090801@redhat.com> <4BD16845.9090001@collabora.co.uk> In-Reply-To: <4BD16845.9090001@collabora.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ian Molton Cc: Paul Brook , qemu-devel@nongnu.org On 04/23/10 11:28, Ian Molton wrote: > Gerd Hoffmann wrote: >> Hi, >> >>> 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?) >> >> Usually qemu takes the server part, i.e. for serial ports you usually do >> '-serial telnet::$port,server,nowait', then 'telnet $host $port' to >> connect to your virtual serial line. When the connection drops, just >> re-run telnet. >> >> In my usage of qemu I didn't came across a use case which needs qemu >> reconnecting yet. > > You're comparing apples with oranges :-) IMHO I don't. > That example is the opposite of whats happening in my case - qemu must > act as a client in order to connect to an EGD daemon. Sure. If I have the choice I usually pick qemu taking the server role. For the egd case there is no choice, qemu has to be the client. Which makes egd a special case, so we could handle the special needs in the egd bits. > Seriously, if virtio-rng is the only thing on qemu that acts as a socket > *client* I'd be amazed. You can configure any chardev to be a tcp client. I never do that though as I find it much more convenient to configure it as server. > And really, is having the ability to reconnect to a service so terrible? No. Lets step back. We want: Allow linking the egd entropy data stream to any device virtio-rng, isa-serial, virtio-serial, whatelse. Which means the reconnect and rate limit logic should *not* sit in virtio-rng but in the chardev feeding the device. Agree? Ok, now for the chardev we have basically two choices: (1) Create a special egd chardev backend which handles reconnects and rate limiting automatically. (2) Add options for reconnect and rate limiting to the socket chardev backend. For (1) you can (at least initially) simply hardcode sensible rates and reconnect retry times for egd needs. I suspect it is the easier road for you. With (2) the reconnect/rate limit bits are reusable for other use cases. Which is nice indeed. But designing the config options part will become a bit more tricky then, because you can't ignore possible other use cases then ... cheers, Gerd