> To be fair, Øyvind needs to address some similarly pointed questions: > > * Were these changes discussed on the list before your patches were > committed, or did it arise as a consequence of them? I do not remember > seeing prior notice, but I understand less than all of the traffic on > this list. Clearly, changes of this scope should have been discussed > before going wild with the tree, given the reaction we are now seeing.
I aired them and got very little reaction. This didn't surprise me too much, because in OpenOCD there are still a lot of large construction/refurbishing works in progress. Sometimes we have discussions on topics, other times just silence. > * Do you have a concrete plan in-hand for restoring USB performance? > >From my understanding, this same mechanism would have been useful for > TCP/IP interface, so I hope you have a similar means already in mind. > If not, you may have dug yourself a big hole that I cannot fill for you, > but I am prepared to let you keep digging. Yes. Profiling, profiling, profiling and then a few tweaks to the code. "all" that is needed is to do postpone the postprocessing a bit more manually in the user code. My first step is simply to add a counter of # of times the jtag queue is flushed. This crude measure should be pretty effective when stepping through the code, just watch the counter increase... Also the community has already provided some performance numbers (Magnus Lundin) that we can measure progress against. Interestingly this could perhaps be used for performance regression testing in that we can run a test and the print # of queue flushes that we see for an operation, so it is independant of device type(i.e. you can run these tests on the parport and it will help ft2232). Each queue flush costs 1-2ms on a USB device, which is on par with local ethernet... Ref. my posting more advanced schemes would include stack traces of long queue flushes... > * If you cannot explain (or demonstrate soon) how you will restore > performance, will you revert these changes and help form a new plan? > If all goes well, you will get us past the regressions; if not, you will > need to admit defeat -- even if it means re-implementing the same > functionality again (but more cleanly this time around). If you cannot > agree to this, we might end up marking your hole with a tombstone. ;) If I don't show steady progress over the next days + week or two, then I'll discuss terms of surrender for sure. :-) > """ > Øyvind agrees to fix the regressions caused by the removal of the > in_handler functionality within one week (by May 15, 2009, 12:00 UTC), > or he will (a) revert his patches to return the original functionality > or (b) or add functionally-equivalent code that improves the concept. > """ I'll discuss terms of surrender if I'm not ajour on functional regressions by the end of next week. W.r.t. performance I think it is reasonable to allow more time (two weeks) so that I can commit things more slowly so as not to jepordize quality as much. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
