Pete Batard wrote: > 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
Most of the libusb community has plenty of clue actually, but I understand that the assumption can look adventurous. Look into the reasons for the depth limit in the USB spec and you'll find that it is really not likely to change anytime soon, backed up even further by the moderate frequency of new USB standards being published. Like you, I expect that new USB specs will bring changes, and I think that a programming library which wants to stay convenient across spec versions will need various changes along with spec changes, but I also know that backwards compatibility is a very high priority for the USB specification, as we see from the low number of "visible" changes from 1.0 through 3.0. It makes no sense to try to design upwards today for a completely unknown and certainly unlikely future, while the depth limit hasn't changed over more than 15 years of USB so far, and with a core design goal for libusb being convenience. This means taking some risks and making smart guesses about what is useful or not, based on experience.. > who knows if some prominent USB committee member, ..as opposed to erring on the side of caution, based on speculation. You may suggest that guessing based on experience is speculation too, but I think the better term for that is projection, and I consider them to be very different. > 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. It's less convenient and every API user for the foreseeable future will think "wtf how stupid is it to have to provide a size here." If you want to always play safe then I think you may want to look more at OpenUSB, which came about from the desire of design goals different from those of libusb, and the safety you mention fits well there. Of course you can and should take libusbx in the same direction if you want. There's in any case also a way to completely avoid all risk while at the same time providing a possibly even more convenient API, by returning a const char *path with a known format, suitable for sscanf(). I think this is even more convenient because the API returns text, which fits much better for both user interaction and storage. > >> + /* 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 commit is a subset of the proposed commit, and doesn't explain the comment at all. But thanks for pointing out the original commit! > 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(). That's quite limited. > >> +libusb_device * LIBUSB_CALL libusb_get_parent(libusb_device *dev) > >> +{ > >> + return dev->parent_dev; > >> +} > > > > Are all devices refcounted by their children? > ... > 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. I think it's too limited for the API to be worthwhile. It introduces a unique restriction not seen previously in the libusb API. //Peter ------------------------------------------------------------------------------ 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
