Re: [Libusb-devel] libusb 1.0 API draft

[Sophia Li <Sophia.Li@Sun.COM>]

G. Del Merritt wrote:

>> callback_handle should be the last argument since it is a return 
>> argument.
>>   
> 
> 
> Heh.  That's a stylistic issue that is long in the tooth.  C.f. 
> strcpy(), strcat(), memcpy(), and *printf() which contraindicate your 
> supposition.  I.e., "put lhs 'result' data on the left-hand-side of the 
> parameter list".    Then contrast those with bcopy() just for fun; it  
> puts the destination on the rhs.

It makes it consistent with the rest of the API so it is not purely 
stylistic.


> 
> 
> "Should be allowed"?  It really depends on how someone tries to do 
> something clever, I think.  For example I could write the archtypical 
> USB-camera library, with cute/simple APIs to get pictures, traverse 
> JPEG/MPEG/etc. data.  Someone else could write the best-of-breed PDA USB 
> library that would know how to synchronize N devices.  Some third clever 
> person could then write an application that helps you manage your camera 
> images to your PDA, hoping to use the two libraries.  If both used 
> libusb in it's 0.1.x or 1.0devel-current forms, that third developer 
> would be out of luck.

The individual library can be designed to only supply device specific 
functions, like getting pictures or PDA synchronizing. The USB bus 
initialization and device probing work can be left to the application to 
do. So it is just a usage problem, not key to the API itself.

I agree with you the key is the API should be made multi-thread safe. If 
libusb_init() implementation well supports reentrancy, it can be called 
whatever ways.



Sophia