On Sat, 2009-12-05 at 13:26 -0800, David Brownell wrote:
> 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... :)
See copy_command_context(). :)
> > 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!
I have looked to improve it, but there could be a lot of work for
relatively little reward.
> 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 am very much interested in more encapsulation, but your proposal
implies a lot of work with the current command set. I think it will be
better to finish separating mechanism and policy, implementing these
extensions in a parallel command language, and making a flag day of it.
> 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.
Yes. I have been looking at adding generic context mechanisms to solve
these problems. I have not found a solution that will KISS.
> (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.)
Right... I intend to piggyback on the Jim stuff, but in a way that
encapsulates it from the rest of the system. Under the hood, this
should be portable to Lua, Scheme, etc.... ;)
> 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
Did you see my proposal to have 'command proc foo bar baz {} {}' syntax?
Does the same thing you're saying, but with less context. ;)
And you could 'eval' such a statement to dynamically scope it....
I am not keen on the idea of the user being able to specify a "current
context" that temporarily changes the implied root of the command tree,
which seems to be what you're suggesting. I would rather have us
standardize on a idiomatic nomenclature that provides a unified syntax
for single target systems that meshes with complex configurations too.
> 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.
Yeah, clearly there remain some missing bells and whistles.
[[Rant about how new features would pay better than cleanup deleted.]]
--Z
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
