On Thu, 2009-12-03 at 09:20 +0100, Øyvind Harboe wrote: > > The public API _must_ be a non-inline version of the API that calls the > > inline version. Period. > > You don't explain why this is necessary and I don't agree. I believe > you assume that it is impossible to allow the minidriver to inline > *and* support an ABI. Actually you can, but the choice is made > compile time on the particular platform. > > The minidriver should be able to take over and *inline* jtag_add_xxx() > fn's if that is the right thing to do on a particular platform.
This is an important point: if you want your ZY1000 to provide an inline version, then you should be able to do that. > Similarly the classic minidriver must be able to implement jtag_add_xxx() > as non-inline fn's to support an ABI. > > > Inline functions may not be used in public APIs, because they prevent > > upgrading shared libraries. > > The statement above is wrong. For a platform with an ABI for shared > libraries you use a minidriver(the "classic" one) that *does* allow > shared library ABI, on an embedded platform you use the minidriver > that removes this unecessary layer. Right, for situations like yours, it does makes sense to allow inline functions. For shared libraries, however, my statements stand. And those are public APIs. Your platform has no public APIs and never will, because you're statically linking the everything into one binary... right? So my statements are fully correct, and your reading of them was too incorrect. ;) Anyway, I think that I might have fixed everything that I was annoyed with in the patches I just pushed. Take another look at things and tell me what you think needs to be done now.... :) --Z _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
