On 2012.08.31 20:40, Hans de Goede wrote: > The reason I'm still responding is that if I've understood correctly, > the thing sparking this discussion is a property of winusb to treat > short packet reads as errors.
Yup. That and #20 for Linux and Windows (report OS driver name [1]), prompted by Alan and others, #24 for Windows (report OS specific location ID [2]), and likely a couple others that haven't made it as actual enhancements. > I would like to turn out that this is > not unique to windows / winusb. Linux has a similar flag, for Linux it > is per urb / transfer, and the current libusb Linux code already uses > it in case of large bulk transfers which it splits in multiple smaller > ones. OK. I certainly see no objection turning what looks like an OS-specific call into a regular API one if more than one platform have a similar feature, and we don't expect that feature to go away or change shape anytime soon. But right now, it looks to me like #24 would be OS specific, so I still wouldn't mind hearing everybody's view on how they think it would be best addressed. I'll also add that one feature I wouldn't mind having with OS specific calls is the ability to remove any of the ones we find too taxing (i.e. ones that create more issues than we bargained for, or become a PITA to maintain), or that the OS deprecates (eg usbfs specific calls). The advantage of doing OS specific triage from a single function call is that we can do some of that by returning NOT_SUPPORTED/void for any operation we decide to drop. Of course, we can do the same for individual calls if we go that route, but in that case we'll have to leave an old empty shell in our API. Then, if we add a statement: "OS-specific calls are provided AS IS - libusbx makes no guarantee that they are going to be carried from one version of the library to the next", it should give us enough flexibility to deal with operations that may be less permanent than the ones that basically come from the USB specs. By the way, it might be worth reminding everyone that we have a boolean libusb_has_capability() call [3], that currently doesn't serve much purpose, but that could also come into play with some of what we're doing here. > This assumes that the winusb flag causes the ep to halt when the short > read is encountered Should be easy to check with a trace. I'll try to get back to you on that. Regards, /Pete [1] https://github.com/libusbx/libusbx/issues/20 [2] https://github.com/libusbx/libusbx/issues/24 [3] http://libusbx.sourceforge.net/api-1.0/group__misc.html#ga9b8e324d28c624cd0b8e7ba21607b8db ------------------------------------------------------------------------------ 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
