qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Date: Mon, 10 Aug 2009 09:27:01 -0500
User-agent: Thunderbird 2.0.0.21 (X11/20090320)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]