From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MM4nc-000590-Fi for qemu-devel@nongnu.org; Wed, 01 Jul 2009 14:44:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MM4nY-00056Y-1e for qemu-devel@nongnu.org; Wed, 01 Jul 2009 14:44:51 -0400 Received: from [199.232.76.173] (port=58270 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MM4nX-00056V-JI for qemu-devel@nongnu.org; Wed, 01 Jul 2009 14:44:47 -0400 Received: from mx1.redhat.com ([66.187.233.31]:42744) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MM4nX-0004Qk-6U for qemu-devel@nongnu.org; Wed, 01 Jul 2009 14:44:47 -0400 Date: Wed, 1 Jul 2009 19:44:44 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1) Message-ID: <20090701184444.GB24144@redhat.com> References: <20090701162114.GB24296@redhat.com> <4A4BACA7.5050406@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A4BACA7.5050406@codemonkey.ws> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org On Wed, Jul 01, 2009 at 01:36:23PM -0500, Anthony Liguori wrote: > Daniel P. Berrange wrote: > >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. > > > > Shouldn't it just be the character devices put on vc's? The 'vc' concept is a stateful one, requiring the user to switch betweeen channels statically and is opaque to VNC clients - all they see is a framebuffer with no idea that QEMU has this magic sequence to change what the framebuffer displays, nor what vc's are available. The idea of this extension is to make data streams a protocol level concept so they can be more intelligently handled by the client, with the VNC protocol extension not being QEMU specific, so our VNC servers could make use of this in ways that suits. > Does snooping imply read-only? That would be pretty unfortunate. No, its fully read-write. My gtk-vnc client so far only does reads, but the QEMU server allows read+write - see the comments about the protocol messages in the 2nd patch for details. 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 :|