From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MM4q2-0006Lq-Ax for qemu-devel@nongnu.org; Wed, 01 Jul 2009 14:47:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MM4px-0006Jx-2x for qemu-devel@nongnu.org; Wed, 01 Jul 2009 14:47:21 -0400 Received: from [199.232.76.173] (port=40885 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MM4pw-0006Jo-ST for qemu-devel@nongnu.org; Wed, 01 Jul 2009 14:47:16 -0400 Received: from rv-out-0708.google.com ([209.85.198.247]:31981) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MM4pw-0004og-FZ for qemu-devel@nongnu.org; Wed, 01 Jul 2009 14:47:16 -0400 Received: by rv-out-0708.google.com with SMTP id b17so334432rvf.22 for ; Wed, 01 Jul 2009 11:47:15 -0700 (PDT) Message-ID: <4A4BAF30.8020609@codemonkey.ws> Date: Wed, 01 Jul 2009 13:47:12 -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> In-Reply-To: <20090701184444.GB24144@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: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. This would be useful outside of VNC too. Regards, Anthony Liguori