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

[Daniel P. Berrange]

On Wed, Jul 01, 2009 at 07:30:23PM +0200, Gerd Hoffmann wrote:
> On 07/01/09 18:50, Daniel P. Berrange wrote:
> >On Wed, Jul 01, 2009 at 06:42:31PM +0200, Gerd Hoffmann wrote:
> >>   Hi,
> >>
> >>>The key requirement here is that it should not
> >>>be neccessary to specifically configure each character device to make
> >>>it available via VNC.  The admin should be able to configure the char
> >>>devices with all current available backends (file, pty, null, tcp, udp,
> >>>unix, etc), and regardless of this config be able to snoop on data from
> >>>any active VNC client on demand.
> >>Hmm.  What is the reason to handle vnc different from
> >>unix/tcp/pty/whatever?  I would expect something like '-serial
> >>vnc,name=foo' here ...
> >
> >As I tried to explain, I want to be able to configure the serial devices
> >using the existing backends *AND* also have the ability to occassionally
> >access the data using a VNC client.
> 
> That doesn't answer the question why vnc should be different.
> 
> 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 

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. 

Thus the CharCaptureOps/State bit of my patch would just be another
CharDriverState impl, that gets added/removed on the fly. The
CharMonitorOps/State bit would still be needed to allow monitoring
of device creation/deletion.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|