From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MM2Yk-0003HV-DO for qemu-devel@nongnu.org; Wed, 01 Jul 2009 12:21:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MM2Yf-0003E2-7B for qemu-devel@nongnu.org; Wed, 01 Jul 2009 12:21:21 -0400 Received: from [199.232.76.173] (port=37317 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MM2Yf-0003Dz-2w for qemu-devel@nongnu.org; Wed, 01 Jul 2009 12:21:17 -0400 Received: from mx1.redhat.com ([66.187.233.31]:45356) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MM2Ye-0001Lt-MA for qemu-devel@nongnu.org; Wed, 01 Jul 2009 12:21:16 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n61GLFLJ021125 for ; Wed, 1 Jul 2009 12:21:15 -0400 Received: from file.fab.redhat.com (file.fab.redhat.com [10.33.63.6]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n61GLEB1012082 for ; Wed, 1 Jul 2009 12:21:15 -0400 Received: from file.fab.redhat.com (localhost.localdomain [127.0.0.1]) by file.fab.redhat.com (8.13.1/8.13.1) with ESMTP id n61GLEqO004925 for ; Wed, 1 Jul 2009 17:21:14 +0100 Received: (from berrange@localhost) by file.fab.redhat.com (8.13.1/8.13.1/Submit) id n61GLEHH004734 for qemu-devel@nongnu.org; Wed, 1 Jul 2009 17:21:14 +0100 Date: Wed, 1 Jul 2009 17:21:14 +0100 From: "Daniel P. Berrange" Message-ID: <20090701162114.GB24296@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1) Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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 :|