Hi all, I did not think I needed to get involved in this thread, but I feel that my contribution at this point might be to help resolve the situation.
I ask that the community actually give Øyvind a chance to finish his work with in_handler. His opponents are shouting on the list without providing sufficient logic and reason, and this needs to stop at once. I have _yet_ to see a solid argument against the removal of this code. Aside from a temporary loss in performance, there have not been clear and present reasons to keep these features. I will concede there have been glimmers of hope here and there, but nothing entirely substantial. Instead, most arguments against removing in_handler have been largely about preserving a legacy design and retaining existing performance. These are not sufficient reasons. The remaining hopefuls were never articulated in a logical and consistent manner, which makes me doubt the trains of thought that delivered these near-misses of reason. The code that is being removed is ugly and needs to be implemented in a cleaner manner. I am willing to believe Øyvind when he says that the performance will be regained after this removing code, but that issue remains to be resolved to the community's satisfaction. No surprise. Many architectural improvements need to be made in OpenOCD, and I do not see anyone else trying to make them. Rome was not built in a day, yet it would take a miracle of that magnitude for these changes to be finished without allowing for ample time, hiccups, and resistance. Until now, all of the arguments have lacked sufficient context for me (a relative OpenOCD novice) to understand why these changes justify such heated passion. At this point, I have heard a lot of emotive pleas, but very little logical reasoning based on the sufficient presentation of corroborative facts. Unfortunately, this assertions holds for all parties involved, so I have some questions to rattle everyone's cage. The skeptics need to address the following issues for the community: * Are you _certain_ the current bugs being experienced cannot be the result of other bugs that were uncovered by the removal of the in_handler code? If they are, Øyvind just did us a service. * Are you _positive_ the "lost performance" will not be regained by any other means? If it can, then that argument is insufficient. * What is the proverbial OSI-like stack for OCD/JTAG that was mentioned? If it is not fully documented, we are not waiting for that to be done; if it is, can I get a URL to it? * How _exactly_ does the in_handler callback fit into it? Again, this needs to be explained in fairly complete technical detail. Or maybe someone can link to the on-line documentation.... * Where are the patches to finish implementing this work? My impression has been that this feature is mostly "for future use", and that is not a sufficient reason to keep it -- unless it is being actively worked on. Show me the "lost work" by answering the above, and I will defend you. If this is not forthcoming, then it is in our interest to continue on the current path, despite any further objections. 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. * 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. * 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. ;) Both sides need to step up with unambiguous answers to my questions, as this controversy continues our recent record of displaying the kind of interpersonal volatility that turns off users and contributors alike. At this point, neither side can win this argument, but everyone can save face and show the community that we can work together professionally. An openly negotiated compromise needs to be reached as soon as possible, so I propose that everyone in community agree to the following statement (in the hope that I can lead us there in one stroke): """ Ø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 think this is a very reasonable compromise, given my read on things. Further evidence may change my perspective, but that is what I see now. Sincerely, Zachary T Welch Corvallis, OR _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
