[Top][All Lists]
[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 :|
- Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1), (continued)
- Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1), Anthony Liguori, 2009/07/01
- Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1), Gerd Hoffmann, 2009/07/01
- Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1), Anthony Liguori, 2009/07/01
- Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1), Gerd Hoffmann, 2009/07/01
- Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1), Anthony Liguori, 2009/07/01
- Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1), Gerd Hoffmann, 2009/07/01
- Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1), Jamie Lokier, 2009/07/01
- Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1),
Daniel P. Berrange <=
Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1), Anthony Liguori, 2009/07/01