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

["Daniel P. Berrange" <berrange@redhat.com>]

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

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