I'm concerned about doing a lot more work on 0.4. I would like to see what our track record is with this amount of changes w.r.t. breakage.
The changes you are proposing look *great* but I wonder if they shouldn't be spread out over 0.4, 0.5 and possibly also 0.6 to get enough feedback on the work along the way. I'm also concerned about such a major change as introducing support for multiple interfaces where I have yet to hear anybody actually needing to do such a thing in-process. It greatly improves the architecture for sure and the code will be more pleasurable to read & work on, important in an open source project in itself. I would put symmetric parallel processing way above it, but I have yet to hear such requests even. When it comes to cleaning up global state(a precursor to multiple jtag interfacs), then my favorite would be to abolish jtag_set_end_state(). Even "simply" getting rid of jtag_set_end_state() would require a *vast* amount of regression testing on real hardware. While putting the end_state into the interface structure would "work" it would be lipstick on a pig, I would much rather push the end state into the target layer. Presumably there would be no need to coordinate end state across a heterogeneous JTAG chain or if there were, then I suspect a naive concept of a global end state per interface would be insufficient. What I would like to see pushed before 0.4 are sweeping changes with low risk profile, so as to make branches easier to maintain. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
