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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
