Re: [OpenOCD-devel] OpenOCD on Windows and USB issues due to misunderstanding

[Andreas F. <and...@gm...>]

On Tue, Jun 25, 2013 at 12:03 PM, Paul Fertser <fer...@gm...> wrote:

> Hello,
>
> On Tue, Jun 25, 2013 at 05:36:24PM +0800, Xiaofan Chen wrote:
> > And right now the best supported driver for libusbx
> > is still WinUSB, so yes it makes sense to recommend
> > users to use Zadig to install WinUSB drivers.
>
> But for the instructions to be fully streamlined
> (i.e. adapter-independent, as in "no matter what usb adapter you have,
> just install winusb with zadig and you're good to go") OpenOCD should
> start using libusb-1.x for vsllink, usbprog, rlink, ulink and
> armjtagew. Is any of these devices composite? If not, then using
> libusb-1.x for them wouldn't break anything (as all the others are
> using libusb-1.x already). Since I have no hardware to test, I
> proposed to use libusb-compat-0.1 as an easy way to unify the API
> used.
>
>
Well, libusb-compat-0.1 won't unify the API, rather the opposite. Unless
you want to settle on libusb-0.1 as the common API and port all other
drivers to it. What it does is enable a *packager* to opt to link OpenOCD
against either libusb version, and that in turn enables end users to opt to
use the WinUSB driver instead of the libusb0 driver for those devices.

Note that it's he who builds that decides whether or not to use
libusb-compat, not us developers. Of course, we can give recommendations.
The benefit for *us* with libusb-compat is that we don't have to do
anything with the current drivers and still give packagers/users the above
choice. On the other hand it relieves us from having to clean up and unify
the USB code (that's a bad thing), which would make it easier to implement
new fancy features (such as auto selection of interface config based on the
connected devices). It's also a maintenance burden to have two ways of
doing the same thing in the same code base.

If we want to unify the API, I see no reasonable option other than porting
the remaining drivers you listed over to the libusb-1.0 API, replacing the
common layer in drivers using it with it's libusb-1.0 version and then
ditching the common layer entirely.

It shouldn't be too hard to port the "unported" drivers. I have tweaked the
rlink code previously and I have the hardware, so I can take on that one.

/Andreas