On Sunday 29 November 2009, Zachary T Welch wrote: > Note: this audit revealed some potential bugs with the command context > implementation. There was a reason that commands were added at the > end of the list. Shallow copying of command_context means that > the list is shared between them.
When does OpenOCD do shallow copying of such contexts? That kind of detail is stuff I've not had to observe... :) > And commands added at the top-level > before the pre-existing commands will not be available in the shared > context as they were before. Yikes! Hmm ... this sounds like a mechanism not being used well! Lexical scoping is a Good Thing, and builds on such hiding. Requiring everything to be globally scoped ... not ideal. Have you thought about having a tree of command contexts? Possibly modeled with stack push/pop type primitives. Have builtin Jim primitives in the base context, various OpenOCD addons next, and then a scan chain ... with each target its own context, with unique operations. I confess to not having dived into this part of the code, but at a glance it seems like "command context" might be the most natural structuring tool that lets us get away from globals. (Previous hand-wavey comments from me said "interpreter", which was the appropriate abstraction in one system I used. And in this one, it's not unrelated -- interpreters do have private state. But, it seems, just for Jim stuff; not for all the OpenOCD machinery.) That is, while there can be $TARGETNAME objects in a context with subcommands ... having $TARGETNAME be the current target might be the same as just stacking it as a context. Its sundry commands might then be accessible without a $TARGETNAME prefix. Likewise, scan chain (or board) specific scopes, and commands needed to work with that chain/board. A "proc ..." declaration would go into the current context If you're keen on growing OpenOCD to support multiple JTAG adapters, and thus multiple scan chains ... I would think that having a clean way to scope things would be near the top of the list of necessary structural changes. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
