From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MM3dj-0004kZ-8M for qemu-devel@nongnu.org; Wed, 01 Jul 2009 13:30:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MM3de-0004ch-Fo for qemu-devel@nongnu.org; Wed, 01 Jul 2009 13:30:34 -0400 Received: from [199.232.76.173] (port=34458 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MM3de-0004cQ-2y for qemu-devel@nongnu.org; Wed, 01 Jul 2009 13:30:30 -0400 Received: from mx2.redhat.com ([66.187.237.31]:49761) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MM3dd-00077Y-K8 for qemu-devel@nongnu.org; Wed, 01 Jul 2009 13:30:29 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n61HUS01009985 for ; Wed, 1 Jul 2009 13:30:28 -0400 Message-ID: <4A4B9D2F.5000607@redhat.com> Date: Wed, 01 Jul 2009 19:30:23 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1) References: <20090701162114.GB24296@redhat.com> <4A4B91F7.9010206@redhat.com> <20090701165039.GF24296@redhat.com> In-Reply-To: <20090701165039.GF24296@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 On 07/01/09 18:50, Daniel P. Berrange wrote: > 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. That doesn't answer the question why vnc should be different. I *do* see the point of being able to have more than one way to access a chardev at the same time. But when building up that infrastructure: Why stop half-way through and make it a special hack for vnc? I think it would be *far* more useful to make chardevs in qemu work that way all the time. Each serial-type driver gets a name tag (either user-specified or autogenerated). chardev backends connect by name. Advantages: (1) It is a step forward to a clear split of guest and host state. (2) Better test coverage because everybody uses the same code paths. (3) You can connect multiple backends to the chardev. For example you can log the console to a file and work interactively via pty at the same time. (4) We can allow multiple connections for unix/tcp sockets (pretty much like the vnc server handles multiple clients today). Bonus points for making that configurable via monitor, so you can start console logging on the fly. serial console via vnc data stream then will be just the sugar on top ;) > VNC is not intended to be the main > character device backend here I'd like to question the concept of a "main chardev backend". cheers, Gerd