On Wed, 2009-12-02 at 14:44 -0800, Zach Welch wrote: > On Wed, 2009-12-02 at 14:32 -0800, Zach Welch wrote: > > On Wed, 2009-12-02 at 22:54 +0100, Øyvind Harboe wrote: > > > >> + > > > >> +/* The minidriver contains inline versions of JTAG fn's */ > > > >> +#include "minidriver.h" > > > >> + > > > > > > > > This is bad, as you are creating a new layering violation that will need > > > > to be removed. You should move this #include to somewhere other than > > > > what should be our public API, probably inside the C files that need it. > > > > Presently, this change exposes _more_ internals, not less. > > > > Let me emphasize my point above: remove the #include from jtag.h. > > Do not expose it outside the JTAG layer. If it is a public API too, > > then you must rename the inline version and call it from a new wrapper > > function in jtag/core.c. You are exposing all of the minidriver to the > > entire system, and that's unacceptable. > [snip] > > Given these hard constraints, I recommend taking another stab at the > > patch and finding a way around this. To be honest, this might reflect > > fundamental design flaws with the minidriver, such that it can only be > > fixed after some rather drastic re-writing of the code. If the code > > relies this heavily on these optimizations, it's broken by design. > > Here's one possible solution: we could #include minidriver.h -- as long > as it is an empty file when installed. This means two versions of > minidriver.h, one that includes the proper jtag_minidriver.h and one > that is empty. In fact, I think you can rename the later to the former > name, then use the -I trick. Then add a mininone/minidriver.h that is > the empty file, which is included when the others aren't. Grok?
I am probably wrong about some details (e.g. renaming), but the goal of this is to eliminate the #if logic from the header files too. That is not acceptable for installed libraries either, so we should not be adding more of that to headers.... The tricks above are similar to those that I used to clean openocd.c of the same logic, so those efforts might help provide you with the required inspiration to solve this. --Z _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
