Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1)

[Gerd Hoffmann <kraxel@redhat.com>]

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