From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MM4vV-0000HR-EK for qemu-devel@nongnu.org; Wed, 01 Jul 2009 14:53:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MM4vR-0000FG-Rt for qemu-devel@nongnu.org; Wed, 01 Jul 2009 14:53:01 -0400 Received: from [199.232.76.173] (port=51362 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MM4vR-0000FA-Kv for qemu-devel@nongnu.org; Wed, 01 Jul 2009 14:52:57 -0400 Received: from mx1.redhat.com ([66.187.233.31]:46180) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MM4vR-0005kI-6u for qemu-devel@nongnu.org; Wed, 01 Jul 2009 14:52:57 -0400 Date: Wed, 1 Jul 2009 19:52:55 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1) Message-ID: <20090701185255.GD24144@redhat.com> References: <20090701162114.GB24296@redhat.com> <4A4BACA7.5050406@codemonkey.ws> <20090701184444.GB24144@redhat.com> <4A4BAF30.8020609@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A4BAF30.8020609@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:47:12PM -0500, Anthony Liguori wrote: > Daniel P. Berrange wrote: > >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. > > I understand what you're suggesting, but I think the right way to handle > this use-case is to allow character devices to be redirected after > initial open making them truly dynamic. The 'vc' reference was puzzelling to me there, but I think you're basically suggesting the same thing as Gerd is ? To fully de-couple the device specification vs backend configuration 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 :|