Consider the simplifications you will have in 99% of all calling code + the JTAG implementations.
The in_handler behaviour can be synthesized on top of the JTAG API layer in various ways and if there is a performance problem, then it will become more clear to the caller how to deal with this (create bigger scans and process afterwards). Also the asynchronous in_handlers have caused a number of hard to trace crashes in the past as they have been operating on stack frames that are out of scope... Additionally removing the in_handler gives greater freedom in how the JTAG drivers can be implemented. Also, there is a potential future benefit in that there is other GPL code out there that will have a MUCH better impeadance match with the OpenOCD code with this cleaned up(which is really my main motivation for cleaning this up...). (PowerPC support over JTAG anyone??? ;-) Sorry about the regression & thanks for finding the problem and reporting it in a productive fashion. This was a systematic mistake and I believe I've committed fixes for the other sites. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
