On 08/10/09 08:55, Amit Shah wrote: >> 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. > > 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. I think the naming is very important. The guest needs to know who is listening on the other end of the line. I think a sysfs attribute (as suggested by Jamie IIRC) will work nicely here. So each device gets a property called 'class' or 'protocol' or something simliar named, therein a string which specifies the protocol it speaks. Host side would look like this: -virtioserial port=4,protocol=clipboard ... in case the protocol is implemented in qemu or like this: -virtioserial port=2,protocol=libguestfs,char=unix:something ... for stuff provided by external apps. Within the guest the two lines above would create vmch4 and vmch2, both having a protocol attribute, and udev then can create symlinks named by protocol, i.e. /dev/vmchannel/clipboard symlinked to /dev/vmch4 and /dev/vmchannel/libguestfs symlinked to /dev/vmch2 The port=<nr> attribute can be optional and dynamically auto-allocated by default. >> So for instance, I could have an "com.ibm.my-awesome-channel" and never >> have to worry about conflicts. reverse fqdn name space is a good idea. We don't need a central protocol name registry then. The examples above would then become something like this: protocol=orq.qemu.clipboard and protocol=org.libguestfs.fish ... and within the guest /dev/vmchannel/org/qemu/clipboard and /dev/vmchannel/org/libguestfs/fish > 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. It's > a system-only thing and should also remain that way. I think virtio-serial is the better way to handle vmchannel. Unlike usb virtio is designed to work nicely in a virtual environment. But vmchannel-over-usbserial should be easy too though in case some guests lacks virtio backports or something. I think you can just stick a name like "vmchannel:orq.qemu.clipboard" into the usbserial product name, then have udev match that and create /dev/vmchannel/org/qemu/clipboard symlinking to /dev/ttyUSB<nr> Voila, you can switch transports and the apps don't even notice. cheers, Gerd _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
