[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v7 RFC 1/2] libxl: Introduce functions to add and remove USB devices to an HVM guest
On 06/18/2014 02:49 PM, Ian Campbell wrote: + ("backend_domid", libxl_domid), + ("backend_domname", string), + ("u", KeyedUnion(None, libxl_device_usb_type, "type", + [("hostdev", Struct(None, [ + ("hostbus", integer), + ("hostaddr", integer) ]))No need to express the host topology I think (because you can build that from the bus,addr tuples)?I don't really follow. You mean, we can drop 'host' from the last two elements, and just call them "bus" and "addr"?Gah, I started writing one thing and then reunderstood usb and wrote half another. What I was trying to say is that you don't need hostaddr to describe the full USB topology path to the device because the (bus,addr) tuple you've given already does so (because each hub effectively creates a new bus number, so they all look like toplevel buses in this representation). You seem to be saying that something is redundant, or that there's extra information somewhere; but as there are only two bits of data (bus and addr), and agree that I need both, I'm having a hard time telling what you think is redundant / could be removed.. "hostdev" is an element of the union; so the structure should unpack like this: struct { libxl_domid backend_domid; char * backend_domname; libxl_usb_device_type type; union u { struct { int hostbus, hostaddr; } hostdev; }; };At the moment, "type" can only be "hostdev"; but I'm envisioning in the future that "type" might be "tablet", "mouse", "keyboard", maybe "mass-storage", and that the union would have more elements. Does that clear things up? Or am I totally confused? :-) -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |