On 2012.05.11 16:48, Peter Stuge wrote: > I think the proposed API could be simplified. There's a hard upper > limit on the path length (7 ports including the HC) so I would > suggest to drop the path_len input parameter and document that path > must be uint8_t [7] or longer.
With software history littered with "this array will never grow larger than X", and with us having no clue how the USB specs may evolve (who knows if some prominent USB committee member, such as intel, may decide that that need to upgrade that limit because they have built a custom system that could use it? The problem with an arbitrary limit such as 7, is that, no matter how much one may expect it to stay the same, it may very well be arbitrarily changed at any time), I would strongly suggest we use the safest approach, that requests a user array to also be provided with its size, as is proposed here. >> + /* The device needs to be open, else the parents may have been >> destroyed */ > > Please explain this comment in more detail? Does it refer to the > libusb_device refcounting? http://libusbx.git.sourceforge.net/git/gitweb.cgi?p=libusbx/libusbx-pbatard;a=commitdiff;h=9dc299236c4f9e58b7281a035a8c35c0cd33e1a3 This is indeed the refcount and ultimate destruction of most of the devices after libusb_free_device_list(), which of course means that one can end up with zombie parents if trying to access these outside of libusb_get_device_list() - libusb_free_device_list(). >> +libusb_device * LIBUSB_CALL libusb_get_parent(libusb_device *dev) >> +{ >> + return dev->parent_dev; >> +} > > Are all devices refcounted by their children? Ultimately (after hotplug), I'm hoping libusbx enum can drop refcounting and maintain a permanent and unique list of devices that remains valid for the duration of a session (a.k.a. the infamous enum process proposal). It is clear that part of libusb(x) during enum aims at duplicating what we would actually like the OS to provide us with, which is an up to date device list, with all the USB properties libusb(x) requires already filled, and preferably cached. If the OS doesn't, I think we could use a layer that does just that. For the time being, the expectation is that the retrieval of a parent is issued within a libusb_get_device_list() - libusb_free_device_list() section, so there's no refcounting. This is of course an important point to mention, which isn't currently done in the API call doc, so I'll make sure this is fixed. Regards, /Pete ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
