qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1)


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1)
Date: Wed, 1 Jul 2009 22:07:50 +0100
User-agent: Mutt/1.4.1i

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 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]