libftdi Archives

Subject: Re: merging of libusb-1.0 support into mainline

From: Mike Frysinger <vapier@xxxxxxxxxx>
To: Xiaofan Chen <xiaofanc@xxxxxxxxx>
Cc: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Date: Thu, 2 Sep 2010 01:44:33 -0400
On Thursday, September 02, 2010 01:16:29 Xiaofan Chen wrote:
> On Thu, Sep 2, 2010 at 11:47 AM, Mike Frysinger <vapier@xxxxxxxxxx> wrote:
> >> Todo:
> >> 1. Rename the library and header file. (not yet)
> > 
> > i dont understand why this is necessary.  why is having libftdi-1.x
> > require libusb-1.x isnt a big deal for distros ?  we have those packages
> > in Gentoo right now.  for packages that still use libusb-0.x API, there
> > is always the compat library.
> > 
> > if the ABI doesnt break, it's actually more of a pain to integrate
> > different SONAMEs into binary distros.  a simple upgrade from
> > libftdi-0.x to libftdi-1.x where one just replaces the other completely
> > is a lot easier, and if it requires a new libusb, then that isnt a
> > problem either.
> > 
> > if there is truly a desire to keep support for older distros which dont
> > support libusb-1.x yet, then adding an internal compat layer isnt hard.
> >  i did this for urjtag already.  so now the whole source uses libusb-1.x
> > but if people are building against libusb-0.x, there is a local header
> > to turn the 0.x API into the 1.x API.
> I think the API is already a bit different. For one thing, please refer to
> this thread.
> -    void ftdi_set_usbdev (struct ftdi_context *ftdi, usb_dev_handle
> *usbdev);
> +    void ftdi_set_usbdev (struct ftdi_context *ftdi, struct
> libusb_device_handle *usbdev);

the structure is never defined in the public USB API, so there shouldnt be a 
binary compatibility issue.  you're merely dealing with a pointer to some 
memory.  the FTDI headers could be changed to merely take a void * pointer.  
the only downside is missed type checking on the prototype, but it would be 
compatible with both libusb 0.x and 1.x and not break ABI.

the only other reason i see for ftdi.h to be including usb.h is for the USB 
endpoint defines.  the ugly answer there would be to replace it with the known 
constants.  or logic like:
# define FTDI_DEVICE_OUT_REQTYPE (USB_xxxx......)

then there would be no reason at all for the public ftdi.h to include usb.h or 

Attachment: signature.asc
Description: This is a digitally signed message part.

Current Thread