I'll give it a go, and I do think I understand what is going on under the hood in some detail.
Also there are a lot of cleanup to be done. And the documentation about some finer technical points is somewhere between bad, nonexsistant or can be found in Dominics thesis paper. Zach Welch wrote: > 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. > The bugs I have seen have all been caused by pushing unteted code into hede. Basically to quick and not careful enough. There were some ideas but this was not a carefull thought out architectural resturcturing. I hope to show that the old code is definetly a carefully planned archtecture. The architecture he proposes will work if cleanly implementd. > * Are you _positive_ the "lost performance" will not be regained by any > other means? If it can, then that argument is insufficient. > It might be regained, but in that case I am positive that we we have either built the same asych callback functionality somwhere else, or trimmed the USB layer, in which case even more performance can be gained by reverting. > * 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? > > No idea, there are layers of course but I am not thinking about OSI stack similarities. > * 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.... > Actually we are talking about two different functionalities here. - The handling of asychronous reads from the jtag, and the extra data treansformation done by the in_handler funtions. In order to issue several read requests where the result should be stored in different locations and avoid doing a full roundtrip for each call, the address of the receiving location is stored in the in_variable field when issuing a scan request to the jtag layer. When a jtag_execute_que() is completed the all oustanding such queued reads are completed. So the calling sequence is - issue as many in scans as possible, - when we need the return walue, call jtag_execute_queue(), if this succeds we are guaranteed that the values are in place. This introduces the potential of receiving value going out of scope, this happens if we ask for a value to be stored in a local variable and exit before calling jtag_execute_scan, which is a type of an "unused variable assignment" The natural place for this functionality is in the jtag layer. The in_handler functionality tells the jtag layer to apply an in_handler supplied with the inscan command to the received value before storing it in the receiving location. This transformation is something that must be done somewhere to adaptet the received jtag data to the data format of the receiving variable. So some part of the code must handle this transformation. And it must be done after receiving the jtag in data and before the result is used. Possible choises are jtag or target variant specific code. Prime example of this is indata from ARM7 scanchain 1. This data is bitswapped. Something users that target read register funtions are not aware of. So the issuer of the Scanchain 1 scan structure tells the jtag layer about this by adding the relevant function to the in_handler field. When the data is received the code has long since move away form this function and we are in the upper layer function that simply expects a u32 value. > * 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. > > The stuff above is finished, it has been used for a long time, cleanup and polishing is always good but this is a core functionlity that is working. > 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. > > Hope this explains the background. Regards Magnus _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
