Re: Device reset abstraction [was: USB device works in linux but not in OSX]

[Peter S. <pe...@st...>]

Xiaofan Chen wrote:
> I am not so sure about libusb.org's attitude about behavior differences
> across different platform. Peter seems to not like this kind of thing.

The fundamental purpose of libusb is to abstract differences about
USB on various systems into a convenient API.

The API and the library is only successful if a program using the
library can be run on all supported platforms without special case
code for any of them and if the program+libusb generates identical
wire activity on the bus for each of those systems. Anything else
is a bug.

Some systems and some use cases have kernel limitations which make
success impossible, but the purpose of the library is to do all the
work of *hiding* differences, not exposing them.

So it doesn't make sense to add platform-specific properties into the
API. In fact, it goes directly against the purpose of the library.


Remember that the API is an abstraction. This means that it may
(and should, whenever it makes sense) create new concepts.

An example of such a concept is the libusb transfer. On some systems
transfers map 1:1 onto a kernel concept, on others they don't. But
for applications using libusb the end result is always identical.
That is a successful abstraction.

I have nothing against adding one or even several device reset
abstractions, but before it is possible to think about what an API
would look like we need to have an overview of the capabilities of
all platforms.

I would suggest to do this in a two-dimensional table on the wiki,
describing exactly what is possible per operating system using which
system APIs.

This thread may already be the best concentration of such information
- I would very much appreciate if someone created that table, perhaps
on a new wiki page, simply gathering the info in this thread.

(If you want to do this and you don't have a wiki account already or
simply haven't been added to the members group then please mention
your username and I'll add you immediately. Of course any of the
other TRAC_ADMINs can do it too, but in practice noone else does.)

It's important to end up with a table that cleary describes what
effect each system API has on hardware *and* software *and* firmware
level, if any.

With such an overview in place it becomes much easier to think about
what new library API

* is possible,
* is convenient, and
* makes sense


Thanks

//Peter