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

[Anthony Liguori]

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
>