[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ian Molton
Subject: Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG
Date: Fri, 23 Apr 2010 16:49:24 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100411 Icedove/3.0.4

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.



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


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

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]