From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MM727-0006Z0-9L for qemu-devel@nongnu.org; Wed, 01 Jul 2009 17:07:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MM722-0006Xf-Im for qemu-devel@nongnu.org; Wed, 01 Jul 2009 17:07:58 -0400 Received: from [199.232.76.173] (port=59055 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MM722-0006XT-Bd for qemu-devel@nongnu.org; Wed, 01 Jul 2009 17:07:54 -0400 Received: from mx1.redhat.com ([66.187.233.31]:38218) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MM721-0001jb-QN for qemu-devel@nongnu.org; Wed, 01 Jul 2009 17:07:54 -0400 Date: Wed, 1 Jul 2009 22:07:50 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1) Message-ID: <20090701210750.GA23349@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A4BC01B.7000100@codemonkey.ws> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Gerd Hoffmann , qemu-devel@nongnu.org On Wed, Jul 01, 2009 at 02:59:23PM -0500, Anthony Liguori wrote: > Gerd Hoffmann wrote: > >Monitor is a special case. Multiple connections to the same session > >are not very useful there. Multiple sessions are a different (albeit > >related) problem. > > Serial is the same. Imagine a bash shell running on the serial port > with two VNC client connected and stdio connected. Utter chaos. You > really want to use one or the other, never both at the same time. If > that's the case, then just switch the character device on the fly. > Don't pretend that we can arbitrate multiple clients at once. This isn't really any different to have 2 VNC clients connected at the same time and using the same Xorg/gnome-terminal instance concurrently. There's no QEMU level technical problem with mirroring updates to multiple clients. For it to be useful though, it does require that the people/thing using each client is 'intelligent', otherwise they'll just end up fighting with each other. So I think this is more of a policy decision - for both VNC clients on the graphical console, and multiple char device clients - for each device you could designate 'exclusive' (only one backend at a time), "exclusive read/write+shared readonly (one backend can read+write, others are forced read only), or 'shared read/write' (every backend can read+write). This kind of policy is done by many traditional VNC servers, and we could add it to QEMU without too much trouble I reckon. For a backend that's intended to be used by some program/service (eg RPC message bus), then exlusive would clearly be required. For a backend that's intended to be used interactively by a real person, then any of the policies could be practical. Regards, 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 :|