[Libusbx-devel] Linux patches for 1.0.9 release

[Pete Batard]

On 2012.03.28 14:32, Xiaofan Chen wrote:
> No this is not what I mean. I mean it is better not to use libusbk.dll
> dependency but rather use Graeme's method (not his codes) to
> use IOCTL to directly talk to libusb0.sys and libusbk.sys. Take
> note libusb0.sys IOCTLs are all covered in libusbk.sys. So the
> codes for libusb0.sys will work for libusbk.sys, you do not need
> to double work.

My worry here is that Graeme designed his implementation specifically 
for libsub0.sys and I'd be weary of assuming that K and 0 can be 
interchanged without hiccup. K may offer some more functionally compare 
to 0, that we'll need to handle. Also Graeme added URB splitup whereas 
this is not needed for WinUSB => adds an extra layer that is better removed.

> If you do not like Graeme's codes (you may have very good reasons),

Many people seem to think that it's a matter of liking. It's more of a 
matter of having to deal with unfinished code (or at least not finished 
to the standards I wanted to see in code I'd have to maintain), with 
unnecessary addons as well as dangerous practices, and that the original 
author had no plan whatsoever to support. I dealt with it exactly as I 
would, as maintainer of the Windows backend: "good start, but it could 
use some fixup" and pointed Graeme to the issues I spotted. His reply 
was (more or less literally): "I've never wanted to spend more than a 
few days on libusb0.sys support, so just take it or leave it..."

> what I propose then is that we'd better not to depend on libusbK.dll,
> but rather reuse libusbk.dll codes (use BSD option) and integrated
> them into libusb-1.0 Windows backend.

That's pretty much been my plan all along, except we can do it in 2 
steps in order to ensure that our users get the feature sooner rather 
than later. Or do you see an issue with going with a K dependency for 
some time and then remove it when we see clearer? Doing things gradually 
looks like the sensible approach here, especially when they pretty much 
beg to be done this way.

> Take note libusbk codes are not compatible with Cygwin/MinGW gcc so
> there will be some work to integrate the codes.

Which is why I'd like to break down the whole 0/K support process in 2 
steps, first with K.dll dependency and then remove it.

Regards,

/Pete