On Jun 24, 2009, at 1:32 PM, openocd-development-requ...@lists.berlios.de
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.
Rob
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
