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: Fri, 07 Aug 2009 09:14:43 -0500
User-agent: Thunderbird 2.0.0.21 (X11/20090320)

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




reply via email to

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