Re: [Xen-devel] RFC: Proposed libxl USB hot-plug interface

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

George Dunlap writes ("Re: RFC: Proposed libxl USB hot-plug interface"):
> On 03/04/13 16:46, Ian Jackson wrote:
> > I don't see why the backend domain is necessarily invalid for hvm
> > domains.  In the stub-dm, you're going to have both an emulated
> > interface (at the guest-dm interface) and a PV one (at the dm-backend
> > interface).  (Not that this will necessarily be implemented right
> > away!)
> 
> Hmm -- I hadn't thought of using qemu-usb in a stubdom.  But in any 
> case, I think the comment is still valid -- the backend_domain_id is 
> being used for the PVUSB part of the "connection".  (And if an HVM 
> domain has a usbfront drivers, it can of course use this field as well.)

Right.  I think though that the comment is misleading since it appears
to be referring to the protocol field, not some kind of other pv
connection in the innards.

> > I'm not sure mixing in and out parameters in the single struct is a
> > good idea.
> 
> Well it's particularly interesting I think to have it here for the 
> "usb-list" function (in which case the entire structure is written by 
> the library).

Ah yes, I see.

>  We could I suppose have usb-add just put it in the return 
> value instead of modifying the structure in-place.

Maybe that would be better.  I think in-place modifying of individual
structure fields is not really a good idea for the libxl api.  These
structs should be thought of as representations of types, not grab
bags of arguments.

> Initially this would be a union because I had envisioned something like 
> this:
> 
> union {
>      struct { blah blah } host;
>      struct { blah blah } wacom-tablet;
>      struct { blah blah blah } disk;
> };

Right, that makes sense.

> Then it's the same functions to add/remove/list an emulated tablet, or 
> an emulated USB disk.
> 
> > I guess you can set the values to -1 to mean "wildcard" ?
> 
> or LIBXL_USB_DEVICE_HOST_ANY, which is #defined to -1. :-)

Right.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel