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

Anthony Liguori anthony at codemonkey.ws
Mon Aug 10 07:27:01 PDT 2009


Amit Shah wrote:
> Let me explain how we came to this numbering: we first had support for
> 'naming' ports and the names were obtained by userspace programs by an
> ioctl. Rusty suggested to use some numbering scheme where some ports
> could exist at predefined locations so that we wouldn't need the naming
> and the ioctls around it.
>   

Fortunately, if you implement the naming scheme in userspace you get the 
best of both worlds ;-)

>>> 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.
>>     
>
> There are some other problems with usb too: It's not transparent to
> users. Any hotplug event could alert users and that's not desired.

I don't think this is true in practice.  Our goal is not to circumvent 
an OS's policy decisions either.

>  It's
> a system-only thing and should also remain that way.
>   

I don't buy this argument at all.  If you exposed a new usb device that 
no OS had a kernel driver, and you had a daemon running that watched for 
insertions of that device, what OS would that not work transparently on?

I think my fundamental argument boils down to two points.  1) we should 
not require new guest drivers unless we absolutely have to 2) we should 
always do things in userspace unless we absolutely have to do things in 
the kernel.

Adding new kernel drivers breaks support for enterprise Linux distros.  
Adding a userspace daemon does not.  Windows device drivers require 
signing which is very difficult to do.  There's a huge practical 
advantage in not requiring guest drivers.

Regards,

Anthony Liguori

> 		Amit
>   



More information about the Virtualization mailing list