On Wed, Apr 7, 2021 at 1:49 PM Ooi, Cinly <[email protected]> wrote: > > Hi Antonio > > Thank you for the quick reply. I broken it down to two parts in this reply. > The first part is about the dependencies and the second part about why use > aji_client? > > > Part 1: >
Hi Cinly, from what I see, it's libaji_client.so that needs libsafestring.so. The code you have added in openocd doesn't need libsafestring directly. I didn't enter in the details of dlopen() & friends, but maybe it's enough to only load libaji_client.so that will in turn load libsafestring.so? But this is just for reducing the code, not really an important point. Being the libraries loaded at runtime through dlopen() is a good step. OpenOCD can be distributed with aji support compiled in and without the extra libraries. If the user selects aji driver and has the libraries, it will work. Without the libraries he can still use the same OpenOCD binary with other drivers. About your limit of libraries in the same folder of openocd ... I don't see this as a security feature. Plus some linux distribution could distribute the libraries in /usr/lib/ > Please check for me that I am in compliance of GPL-v2. I tried my best, but I > might be missing parts. Where possible can you also check me against GPLv3 > please? The source code for aji_openocd is under GPL-v2+ and we do intent to > go to GPL-v3(+) if and when openocd decides to do it. >From the license side, it seems ok for me. MIT is more permissive than GPL so, if I'm not wrong, it's possible to add MIT code in OpenOCD and to load MIT libraries. There was some discussion about moving OpenOCD to GPL-v3. OpenOCD benefits from code taken by other projects, mainly Linux and U-Boot. These two are GPL-v2 "only". Their code cannot be incorporated in GPL-v3 projects. Plus we have a couple of files in OpenOCD that are GPL-v2 "only". Moving to GPL-v3 will mean dropping these files. Due to these limitations, personally I don't expect the move to GPL-v3 will happen. Your code licensed as MIT can always be linked in another GPL-v3 project. So I believe your question is not strictly about your code but more about the future use of OpenOCD by intel, correct? In any case, if OpenOCD becomes GPL-v3 in version XYZ, you are allowed to fork the project from version XYZ-1 (that is still GPL-v2) and go ahead with the fork as GPL-v2. > Part 2: Clear! The daemon jtagd guarantees concurrent access by different players and bridges openocd to the core inside the FPGA. >From the OpenOCD license point of view, there is no need to get jtagd open-sourced. And for the time being I don't think it is needed for this development. It remains up to intel what to do with jtagd. Maybe I'm missing something, but moving from minidriver to jtag driver does not look so disruptive. interface_jtag_add_ir_scan() and interface_jtag_add_dr_scan() skip the unused TAPs, but the other API just queue the commands. Then jtag_interface->execute_queue() unpacks the queue. Anyway, if you really hit a blocking point, as written in the commit message of http://openocd.zylin.com/6091/ , the minidriver can be back in a modern re-implementation. Antonio
