Øyvind Harboe wrote: >> You can add your stuff for testing, ok no problem. You can put things in >> plase so that I can test and profile potential changes. But you are >> stepping on my toes by changing things I work on. >> > > Let me take this oportunity to thank you for finding and reporting these bugs > in a productive manner even if you disagree with me on this one. I believe > I will win you over, eventually. > > I'm jumping to fix the problems that I've created, this includes performance > problems. > > >> The in_handlers are not depreciated, you are suggeting that they should be. >> a big difference, and I think they should stay. >> > > in_handlers cause various problems: > > - API bloat. It is only used in a few places. > Important places :) > - performance problems on embedded targets. Lots of fn calls and overhead > in the drivers. > If the operation performed by the inhandler is necessary the it must be called anyway somwhere, it is just moved around. > - hard to read code (callbacks are much more opaque than a straightforward > manipulation in the code) > We have event_callbacks, timed callbacks and other fancy stuff. Shall they also be removed ? The in_handlers are actually easier to know exactly when and how they are called. > - I believe that they will *hide* some performance problems that will > now be brought into bright daylight. Using a normal out/in scan + > post processing will be much clearer and faster. > > You may be right about this on embedded openocd hosts (zylin) but for systems with long roundtrips, no !
The actual implementation can be check and perhaps improved. Regards, Magnus _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
