From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MM7Px-0005PX-E1 for qemu-devel@nongnu.org; Wed, 01 Jul 2009 17:32:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MM7Ps-0005Mb-Lf for qemu-devel@nongnu.org; Wed, 01 Jul 2009 17:32:36 -0400 Received: from [199.232.76.173] (port=39428 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MM7Ps-0005MP-FL for qemu-devel@nongnu.org; Wed, 01 Jul 2009 17:32:32 -0400 Received: from mail-px0-f201.google.com ([209.85.216.201]:35396) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MM7Pr-000607-UT for qemu-devel@nongnu.org; Wed, 01 Jul 2009 17:32:32 -0400 Received: by pxi39 with SMTP id 39so30872pxi.4 for ; Wed, 01 Jul 2009 14:32:30 -0700 (PDT) Message-ID: <4A4BD5EB.5060701@codemonkey.ws> Date: Wed, 01 Jul 2009 16:32:27 -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> <4A4BB038.7050401@codemonkey.ws> <4A4BBBE6.2070601@redhat.com> <4A4BC01B.7000100@codemonkey.ws> <4A4BCD80.2000906@redhat.com> In-Reply-To: <4A4BCD80.2000906@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: > With multiple connections and multiplexing: You'll just connect, type > a few commands, disconnect, done. You'll even see what you have done > when you come back to the office the next day. > > Also note that the vnc server accepts input from multiple clients as > well, which can lead to simliar problems. Nobody wants to kill > support for multiple clients just because of that, because in practice > it isn't a issue. I don't disagree with your use-case. What I'm pointing out, is that we need to do some major surgery to get there. The current chardev protocol has no real notion of flow control and assumes a static bidirectional channel between the front-end and back-end. Flow control policy is inconsistent and those decisions are made in the back-end (i.e. tcp:). We really need to push flow-control to be a proper part of the protocol though so that the front-end can participate. For instance, virtio-console/serial is fully capable of implementing flow control. Punting buffering policy to the guest is IMHO the best possible solution to the general problem. Having multiple connections within a chardev really also needs to be part of the monitor protocol because it's fundamental to flow-control. We want the front-end to have enough information to know how many clients are connected and which ones are ready to receive. When dealing with a single I/O source, it should be front-end policy to determine what to do. Certainly, there are some front-ends (like the monitor) that can support multiple I/O sources. Another example is the VNC server which really should be using chardevs. I agree that mirroring is a pretty reasonable policy to map a single I/O source to multiple clients for some devices. That should be a front-end decision though. In this model, I still don't see having two different back-ends connected to a single front-end. I don't know if I agree there's a whole lot of value in that although the implementation is straight forward (a special back-end that unifies multiple front-ends as sessions). Regards, Anthony Liguori