On Thu, 2009-06-25 at 01:17 -0700, Rob Barris wrote: > On Jun 24, 2009, at 1:32 PM, [email protected] > wrote: > > >>> > >>> 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx > >> > >> > >> > >> How would ftd2xx be linked here? Via LoadLibrary (dlopen) and > >> friends? > >> I'd volunteer to create such a solution. > > > > We build and distribute: OpenOCD -> libftdi > > > > Users would download and install libftdi-ftd2xx *instead* of libftdi. > > > > Since they have the same ABI, the application cannot tell the > > difference > > between the open and closed versions. > > > > OpenOCD binaries cannot legally be distributed with the wrapper, only > > with the the normal libftdi. They should behave the same in all > > outward > > function ways; there cannot be any conditional code in OpenOCD to > > enable > > the wrapper library. > > I like the sound of this approach. > > In order to prevent disruption to the existing OpenOCD users, I would > like to suggest that no change be made to the status quo (i.e. you > have to manually enable FTD2XX mode at build time, and that code path > is still there) until this new shim library project has been completed. > > i.e. I think it would be great to go forward when the prerequisite > support is there to do so, however I feel that should be on its own > timeline and the existing level of capability in OpenOCD (fully GPL > compliant or not, this is the status quo) -- should not be allowed to > regress prior to that moment. > > Restated: > > Let OpenOCD 0.2.0 ship with whatever feature set is desired, but > without removing any capability for FTD2XX - *unless* - the new shim > lib is completed and available to mate up with that release. i.e. I > think this is a great thing to improve, but I am questioning whether > it is a priority-1 blocker for 0.2.0, given the history.
We have said it before, but the "official position" bears repeating: """ The FTD2XX driver is legal to build and use on your machine. It always has been and always will be. It is not legal to distribute binaries with that driver. In these respects, we have no reason to remove it from the source code, until such a time as the open source alternative has been shown to outperform it (and the proprietary driver bit-rots). """ Personally, I want to make that day come sooner rather than later. Cheers, Zach _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
