From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MM4uK-0007zP-MA for qemu-devel@nongnu.org; Wed, 01 Jul 2009 14:51:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MM4uF-0007ux-FL for qemu-devel@nongnu.org; Wed, 01 Jul 2009 14:51:47 -0400 Received: from [199.232.76.173] (port=51302 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MM4uF-0007ug-4D for qemu-devel@nongnu.org; Wed, 01 Jul 2009 14:51:43 -0400 Received: from qw-out-1920.google.com ([74.125.92.144]:7915) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MM4uD-0005TP-3t for qemu-devel@nongnu.org; Wed, 01 Jul 2009 14:51:41 -0400 Received: by qw-out-1920.google.com with SMTP id 5so451194qwc.4 for ; Wed, 01 Jul 2009 11:51:39 -0700 (PDT) Message-ID: <4A4BB038.7050401@codemonkey.ws> Date: Wed, 01 Jul 2009 13:51:36 -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> <4A4B91F7.9010206@redhat.com> <20090701165039.GF24296@redhat.com> <4A4B9D2F.5000607@redhat.com> In-Reply-To: <4A4B9D2F.5000607@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: Gerd Hoffmann Cc: qemu-devel@nongnu.org Gerd Hoffmann wrote: > 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: Dynamically changing the character devices backends should be a not too terrible thing to do today and I agree this is the right approach. Allowing multiple readers/writers for character devices is much more complex to get right though. The current chardev API does not have good semantics for just handling one client that connects and disconnects. It certainly wouldn't gracefully handle multiple client states at once. You could do something like a mirrored mode but things get really ugly when dealing with multiple read-write clients. Think of how that would behave with the monitor for instance. I agree that for something like -monitor tcp::1025,server,nowait, you want to be able to connect multiple times and get multiple monitor sessions. We would need a serious overhaul of the character device infrastructure for that (and that's certainly long overdue). So IMHO, this sort of refactoring shouldn't be a requirement for this patch series. That doesn't mean we want to take a VNC specific hack though. Regards, Anthony Liguori