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

[Daniel P. Berrange]

The following two patches make it possible to tunnel character devices
over VNC, using a new VNC extension. This is motivated by the existing
QEMU support for tunnelling audio streams over VNC, and the code follows
a very similar design.  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.

The first patch adds a bunch of support APIs to qemu-char{.h,.c}

 - An API to iterate over all current character devices. This allows
   the VNC server to inform the client of the current list of available
   data streams upon connection

 - An API to monitor creation & deletion of character devices. This
   allows the VNC server to inform the client  when character devices
   are hot-plugged/unplugged.

 - An API to request capture data on a specific character device.
   This is how the VNC server gets the data coming out of the guest

The design for this stuff follows that used in the audio stream capture
APIs (audio/audio.h)

The second patch implements the VNC extension for tunnelling multiple
independant data streams over a connection. I have stolen one of
the psuedo encodings assigned to Anthony for this purpose, and also
added a new message sub-type to the 'aliguori' client/server message
type. Hopefully anthony will approve this allocation if the patches
look good :-)

The VNC extension is for generic data streams, so it can be implemented
by any VNC server that wants this. The QEMU implementation maps data
streams onto character devices. Every data stream has a name, and in
this case I'm using the QEMU character device label, since this can be
explicitly set by mgmt tools starting QEMU, and allows VNC client to
correlate the stream with devices, and with the monitor. When the client
requests capture on a specific device, the server assigns an integer
ID to the stream and that's used in place of the name for all future
messages. The idea is that if you're sending a few bytes at a time of
data, it is overkill to send a 20 byte string with the name whn you
could just send an int32 identifier. I might actually make it an int8.
The wire format for the messages is again closely following the model
used for the earlier audio stream extension.

Regards,
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 :|