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

[Ian Molton <ian.molton@collabora.co.uk>]

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