[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: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1)
Date: Wed, 01 Jul 2009 14:11:23 -0500
User-agent: Thunderbird (X11/20090320)

Daniel P. Berrange wrote:
On Wed, Jul 01, 2009 at 01:47:12PM -0500, Anthony Liguori wrote:
Daniel P. Berrange wrote:
On Wed, Jul 01, 2009 at 01:36:23PM -0500, Anthony Liguori wrote:
Daniel P. Berrange wrote:
The following two patches make it possible to tunnel character devices
over VNC, using a new VNC extension. This is motivated by the existing
QEMU support for tunnelling audio streams over VNC, and the code follows
a very similar design.  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.

Shouldn't it just be the character devices put on vc's?
The 'vc' concept is a stateful one, requiring the user to switch betweeen
channels statically and is opaque to VNC clients - all they see is a
framebuffer with no idea that QEMU has this magic sequence to change
what the framebuffer displays, nor what vc's are available.
I understand what you're suggesting, but I think the right way to handle this use-case is to allow character devices to be redirected after initial open making them truly dynamic.

The 'vc' reference was puzzelling to me there, but I think you're
basically suggesting the same thing as Gerd is ? To fully de-couple
the device specification vs backend configuration

Well, I'm saying, a character device should be exposed via VNC IIF it's connected to a 'vc' backend device. In order to satisfy your use-case, I'd also suggest decoupling the monitor front-end's from back-ends so that you can reconnect a character device to a 'vc' if you want to.

The easiest way (albeit a little ugly) to do this would be to create a pluggable character device that proxied to another character device. Change qemu_chr_open() to return qemu_chr_open_proxy(chr, label).

You can then enumerate proxies by label and retarget the proxy to a different device.


Anthony Liguori


reply via email to

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