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

[Anthony Liguori <anthony@codemonkey.ws>]

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.

Regards,

Anthony Liguori

> Daniel
>