Re: [Libusbx-devel] Compatibility with libusb-compat

[Alan S. <st...@ro...>]

On Mon, 9 Sep 2013, Xiaofan Chen wrote:

> On Sat, Sep 7, 2013 at 11:36 PM, Alan Stern <st...@ro...> wrote:
> > Slightly off the original topic but perhaps still relevant...
> >
> > There are several Linux programs using libusb-0.1 that don't work with
> > libusb-compat.  The reason is that they perform some or all of their
> > I/O using the usbfs API directly, relying on libusb merely for listing
> > devices and opening the device files.  In particular, they get the
> > device's open file descriptor by abusing the interface and reading the
> > value directly out of the private libusb usb_dev_handle structure.
> 
> Just wondering if there are any important programs here. If there
> are not many, why not suggest them to move to libusbx API.

I don't know.  Perhaps not many, but this may include a large 
percentage of unmaintained programs.

For the one noteworthy case I am aware of (the Data Center program from
Total Phase), I suggested to the vendor that they migrate to libusb-1.  
Evidently this had not occurred to them; instead they have been
recommending various work-arounds to their customers.

> Just wondering how easy for these program to migrate to
> mixed libusbx API and directly usbfs API. Or is it faster for
> them to use libusbx API and get rid of the usbfs API?

I don't know.  On the other hand, does libusbx provide an API for 
getting the OS's file descriptor from the device handle?

> I know one of them which is libftdi-0.x async I/O which use usbfs
> directly for Linux. Later libftdi1 migrates to libusb-1.0 API and
> the problem no longer exists.
> 
> > If libusb-compat were changed so that the initial parts of the
> > usb_dev_handle structure were the same as in libusb-0.1 -- including
> > the underlying file descriptor -- these programs might suddenly start
> > working.  (Note that doing this would require adding a function to the
> > libusb-1.0 API for retrieving the low-level file descriptor.)
> >
> > Anybody feel like implementing this?
> 
> How feasible is this?

I doubt it would be very difficult, particularly since the changes can
be restricted to operating systems that supported libusb-0.1
originally.

> I am not so sure if any one wants to further develop libusb-compat-0.1
> other than bug fixes. Travis has done some work on integrating
> libusb-win32 async APIs into libusb-compat-0.1 but the work is
> not published.

This isn't terribly important.  If nobody does the work, it may not
matter much.

I noticed because for some time, Fedora has not provided libusb-0.1
support -- just libusb-compat (although for some reason the package is
named "libusb", which made the situation rather confusing).  In the end
I had to get hold of an old source package for genuine libusb-0.1 and
build it for my current system.

It would be nice to spare other people the need to resort to such 
measures.

Alan Stern