From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O5L9S-0005WI-QY for qemu-devel@nongnu.org; Fri, 23 Apr 2010 11:50:46 -0400 Received: from [140.186.70.92] (port=52112 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O5L9Q-0005V8-Rj for qemu-devel@nongnu.org; Fri, 23 Apr 2010 11:50:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O5L9O-0000dS-M9 for qemu-devel@nongnu.org; Fri, 23 Apr 2010 11:50:44 -0400 Received: from bhuna.collabora.co.uk ([93.93.128.226]:50111) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O5L9O-0000dG-EE for qemu-devel@nongnu.org; Fri, 23 Apr 2010 11:50:42 -0400 Message-ID: <4BD1C184.9030300@collabora.co.uk> Date: Fri, 23 Apr 2010 16:49:24 +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> <4BD09E3F.7070605@collabora.co.uk> <4BD15A0D.6090801@redhat.com> <4BD16845.9090001@collabora.co.uk> <4BD1A998.2020500@redhat.com> In-Reply-To: <4BD1A998.2020500@redhat.com> 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: Gerd Hoffmann Cc: Paul Brook , qemu-devel@nongnu.org On 23/04/10 15:07, Gerd Hoffmann wrote: >>> 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. Well, comparing a connection where qemu is the server to one where it is the client doesn't seem terribly valid to me... >> 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. I really don't think its that unusual... > 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. Perhaps thats because chardev clients are nearly useless right now because they just die if the connection drops... > 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? Yes. > 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. Ok. > 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. But the chardev layer wont reconnect for you. Or are you suggesting that we create another type of chardev, thats nearly like a socket, but speaks egd and can reconnect? That seems hideous to me. > 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 ... But (2) is already done. Ok, the options might be 'simplistic' right now, but whats to say we cant add more (like "burst=foo" or something) should the need arise? seriously, I had thought when you suggested it earlier that a chardev backend was the right way, but now I see that a backend to handle egd would also have to handle connecting etc. and thats just wrong. What we need ideally is something like a line discipline that talks egd. That way it wouldn't matter if it were a socket or anything else that the data came in via, which is the case with the patch as I wrote it - you can feed in EGD from a file, a socket, anything, and it just works. Rolling the EGD, reconnects, connection handling etc. all into a special backend would lose us that functionality, so I'm against that. Have you actually tried the code out? It works very naturally, reuses as much built in qemu functionality as it can, and has a nice commandline syntax I think. What advantage is there in breaking that? -Ian