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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
