From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MM5DT-00031E-A9 for qemu-devel@nongnu.org; Wed, 01 Jul 2009 15:11:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MM5DN-000312-RY for qemu-devel@nongnu.org; Wed, 01 Jul 2009 15:11:34 -0400 Received: from [199.232.76.173] (port=55723 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MM5DN-00030z-LC for qemu-devel@nongnu.org; Wed, 01 Jul 2009 15:11:29 -0400 Received: from mail-ew0-f211.google.com ([209.85.219.211]:40152) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MM5DN-0000M2-74 for qemu-devel@nongnu.org; Wed, 01 Jul 2009 15:11:29 -0400 Received: by ewy7 with SMTP id 7so1272166ewy.34 for ; Wed, 01 Jul 2009 12:11:28 -0700 (PDT) Message-ID: <4A4BB4DB.7070708@codemonkey.ws> Date: Wed, 01 Jul 2009 14:11:23 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1) References: <20090701162114.GB24296@redhat.com> <4A4BACA7.5050406@codemonkey.ws> <20090701184444.GB24144@redhat.com> <4A4BAF30.8020609@codemonkey.ws> <20090701185255.GD24144@redhat.com> In-Reply-To: <20090701185255.GD24144@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org Daniel P. Berrange wrote: > 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 > Well, I'm saying, a character device should be exposed via VNC IIF it's connected to a 'vc' backend device. In order to satisfy your use-case, I'd also suggest decoupling the monitor front-end's from back-ends so that you can reconnect a character device to a 'vc' if you want to. The easiest way (albeit a little ugly) to do this would be to create a pluggable character device that proxied to another character device. Change qemu_chr_open() to return qemu_chr_open_proxy(chr, label). You can then enumerate proxies by label and retarget the proxy to a different device. Regards, Anthony Liguori > Daniel >