|
From: | Gerd Hoffmann |
Subject: | Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG |
Date: | Fri, 23 Apr 2010 16:07:20 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |