Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

[Gerd Hoffmann]

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