libftdi Archives

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

From: Mike Frysinger <vapier@xxxxxxxxxx>
To: Thomas Jarosch <thomas.jarosch@xxxxxxxxxxxxx>
Cc: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Date: Thu, 2 Sep 2010 14:58:59 -0400
On Thursday, September 02, 2010 03:44:05 Thomas Jarosch wrote:
> On Thursday, 2. September 2010 05:47:10 Mike Frysinger wrote:
> > 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.
> 
> The "ftdi_context" structure was expanded in libftdi-1.x,
> IMHO this won't be ABI compatible.

yes & no.  i see the items were added to the end -- good.  and the allocation 
is always handled by libftdi ?  so users will not be doing malloc(struct 
ftdi_context) but rather ftdi_new() ?

in terms of the function of these new fields (async accesses), it isnt like 
people would have to change their code in order to work with the new library 
even if they never utilize async functionality ?  in other words, if i had an 
app today that doesnt use async stuff and works fine, then i shouldnt have to 
make any source changes to it so that it works with the newer libftdi-1.0 ?

if that's the case, then backwards compatibility should be maintained.  the 
emphasis in the world is on newer ABIs being compatible with older programs.  
there is no guarantee of newer programs working with older libraries.

> > 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.
> 
> The keyword here is "older". If the distro is too old to use libusb 1.x,
> then it can also stick to an libftdi 0.x version and don't update it
> either.

i was going to suggest that too.  glad you're already thinking in that 
direction :).

it's not like libftdi-0.18 is "bad".  if that were the last libftdi release 
that supported libusb-0.x, i dont think that'd be a problem for people.
-mike

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

Current Thread