On 2010/12/11 8:20, Andreas Fritiofson wrote:
I don't know. But, generally, if I _can_ register the same handler twice, I'd expect each registration to require a separate unregister call. The actual call sites would have to be inspected before changing this behavior, of course. There shouldn't be many of them, since the bug has gone unnoticed for so long.
Looking at this further, there are only two places that jtag_register_event_callback() is called from, the first from jtag_tap_init() with the a new TAP instance as the priv parameter, and the second from target_examine() with a target as the priv parameter.
The first case I believe can only be called once per unique priv instance by virtue of the fact that it's part of the TAP initialisation and the TAP instance is the priv parameter. The second case only appears to be called from the init handler which is guarded by a static initialized flag.
However, there is nothing to help prevent issues being introduced with their future usage. At the very least the functions should have banner describing the interface contract, specifically whether multiple registration are disallowed, allowed with balanced de-registration, or allowed with only a single de-registration necessary. I think the former with safety checks would be the safest, however this would increase the footprint of change if we were to require consistency.
For now I suggest we can stay consistent with the target based list function implementations? This would appear to imply that multiple registrations are possible but registration / de-registration balance is the responsibility of the client.
I also think the benefits of a common list function here are outweighed by the simplicity of the function (the bug and the generated discussion excepted!) and lost readability in the specialisation casts.
I'd be happy to test and submit a new patch candidate if and when we're all in agreement.
Peter, note that the double pointers are in the target list function implementations (that would be copied), are you ok with this? I think the implementations are concise and readable, though maybe my sensitivity to double pointers has dulled...
Cheers, Paul _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
