On 08/10/09 08:55, Amit Shah wrote:
quoted text
>> 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.


quoted text
>> 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


quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html