Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication

[Anthony Liguori <anthony@codemonkey.ws>]

Amit Shah wrote:
> On (Thu) Aug 06 2009 [18:37:40], Jamie Lokier wrote:
>   
>> Apart from dbus, hard-coded meanings of small N in /dev/vmchN are
>> asking for trouble.  It is bound to break when widely deployed and
>>     
>
> It's no different from the way major-minor numbering works on the Linux
> kernel: they uniquely identify a device.

Bad example.  Quite a lot of modern devices drivers are using dynamic 
major/minor numbers because they have proven to be such a pain in the 
butt.  That's why we have more sophisticated mechanisms like udev for 
userspace to make use of.

We'll definitely need some way to support dynamic vmchannels.  Static 
allocation of ports is just not going to work.  If we did a userspace 
daemon, I'd suggest using some sort of universal identifier that's easy 
to manage in a distributed fashion.  Like a reverse fqdn.

So for instance, I could have an "com.ibm.my-awesome-channel" and never 
have to worry about conflicts.

>> guest/host configs don't match.  It also doesn't fit comfortably when
>> you have, say, bob and alice both logged in with desktops on separate
>> VTs.  Clashes are inevitable, as third-party apps pick N values for
>> themselves then get distributed - unless N values can be large
>> (/dev/vmch44324 == kernelstats...).
>>     
>
> Hm, so there can be one daemon on the guest handling all clipboard
> events. There's some work done already by the fast-user-switch support
> and that can be extended to daemons that talk over virtio-serial.
>   

You could have one daemon that manages all vmchannel sessions.  It can 
then expose channels to apps via whatever mechanism is best.  It could 
use unix domain sockets, sys v ipc, whatever floats your boat.

And, you can build this daemon today using the existing vmchannel over 
TCP/IP.  You could also make it support serial devices.  We could also 
introduce a custom usb device and use libusb.  libusb is portable to 
Windows and Linux.

So we get backwards compatibility, and the Just Works experience with no 
funky kernel drivers.  What's there not to like?

Regards,

Anthony Liguori