Let me add a vote for properties such as location IDs as identified by the
OS. I can se how a general mechanism to retrieve properties would be good.
I actually think it would be fine to rely on the OS headers for properties
names if possible. After all if you are looking for an OS specific property
you know what OS you are talking about. And it would avoid having libusbx
have to play catch up with new properties.
YA
On Friday, August 31, 2012, Pete Batard wrote:
> 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 <javascript:;>
> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
>
------------------------------------------------------------------------------
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
