|
From: | Gerd Hoffmann |
Subject: | Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1) |
Date: | Wed, 01 Jul 2009 21:27:40 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2 |
On 07/01/09 20:50, Daniel P. Berrange wrote:
On Wed, Jul 01, 2009 at 07:30:23PM +0200, Gerd Hoffmann wrote:I *do* see the point of being able to have more than one way to access a chardev at the same time. But when building up that infrastructure: Why stop half-way through and make it a special hack for vnc? I think it would be *far* more useful to make chardevs in qemu work that way all the time.Ok, if i'm understanding correctly, you're suggesting we change the way character devices are configured on the CLI, to be split like the NIC device args eg, instead of -serial file:/tmp/foo.log,name=serial0 we'd do -serial name=serial0 -chardev name=serial0,file:/tmp/foo.log And allow an 1-m mapping for serial -> chardev args
Yes.
This could perhaps be done by having a 'CharDriverState' implementation that was a multiplexor, and allow further CharDriverState instances to be added/removed to this multiplexor on the fly.
Hmm, don't like that idea.
Thus the CharCaptureOps/State bit of my patch would just be another CharDriverState impl, that gets added/removed on the fly.
I'd keep the CharCaptureOps/State and CharDriverState separation as it is now. CharCapture would probably better named CharBackend or simliar. CharDriverState would simply dispatch to all CharBackends connected.
We can keep the old code path working for a while. So we can switch users one by one to the new way. When done zap the old one and make CharDiverState a pure dispatcher for the Backends.
The CharMonitorOps/State bit would still be needed to allow monitoring of device creation/deletion.
Yes. cheers, Gerd
[Prev in Thread] | Current Thread | [Next in Thread] |