From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MM31Y-0004Ch-QO for qemu-devel@nongnu.org; Wed, 01 Jul 2009 12:51:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MM31T-00045B-VK for qemu-devel@nongnu.org; Wed, 01 Jul 2009 12:51:08 -0400 Received: from [199.232.76.173] (port=40142 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MM31T-000448-CF for qemu-devel@nongnu.org; Wed, 01 Jul 2009 12:51:03 -0400 Received: from mx1.redhat.com ([66.187.233.31]:60655) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MM31S-0007Kl-T7 for qemu-devel@nongnu.org; Wed, 01 Jul 2009 12:51:03 -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 n61GofMJ008506 for ; Wed, 1 Jul 2009 12:51:01 -0400 Date: Wed, 1 Jul 2009 17:50:39 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1) Message-ID: <20090701165039.GF24296@redhat.com> References: <20090701162114.GB24296@redhat.com> <4A4B91F7.9010206@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A4B91F7.9010206@redhat.com> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org On Wed, Jul 01, 2009 at 06:42:31PM +0200, Gerd Hoffmann wrote: > Hi, > > > 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. > > Hmm. What is the reason to handle vnc different from > unix/tcp/pty/whatever? I would expect something like '-serial > vnc,name=foo' here ... As I tried to explain, I want to be able to configure the serial devices using the existing backends *AND* also have the ability to occassionally access the data using a VNC client. VNC is not intended to be the main character device backend here - it is just a way to snooping on the data being sent to another backend. For the same reason, audio capture over VNC does not impact the way you configure sound cards to use SDL/pulseaudio alsa/esd/etc, it just gives you the means to capture the audio data when connected with VNC. You could also envision QEMU getting the ability to add/remove display backends like SDL/VNC on the fly. Thus VNC might not even be configured when starting up the guest and specifying character device backend configs. The capture approach deals with that problem trivially. 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 :|