On Fri, 2009-06-12 at 22:58 -0700, David Brownell wrote: > On Friday 12 June 2009, Zach Welch wrote: > > > > > I say "most" issues since (a) there's no interlock between a polling > > > context and anything else, which may eventually trigger SMP issues; > > > and (b) this is one of several areas where the jtag and target layers > > > could stand to interact more cleanly. > > > > This patch makes me twitch: the JTAG layer should not use "target.h". > > How can we do this without introducing a layering violation? > > That's a fine question, and is exactly what I meant by (b). > > I don't have a good answer, but note that [patch 2/3] has > the same requirement to access things that the target code > is keeping excessively close. The "layer" boundaries are > clearly not quite right.
The JTAG layer is clean of target dependencies without these patches (except for the ZY1000 and dummy minidrivers), so I think we should try to implement fixes that preserve this. > For 0.2.0 I suggest not worrying about this; layering is > there to help structure things, not to prevent solutions. > The scope is very limited. *twitch* Slippery slope. Since it's scope is limited, the required abstraction to preserve layering should not be too difficult, right? :) I prefer to avoid adding more layering violations, since I have been working to eliminate these from the system. At the very lest, there should be @todo notes indicating a layer violation is necessary, but that presumes such is strictly necessary. > The flag used in [patch 1/3] might better be modeled as a > global mutex gating ownership to the JTAG stack ... but > that concept isn't there in the code. The target stack > could just stick to a private flags. A mutex seems required for SMP, but it also seems premature. Proper threading support should be a 0.3.0 or later change, but a wrapper to a global seems like a viable transitional solution. > Maybe the stuff in [patch 2/3] would better be modeled > as JTAG events delivered to that TAP. Target code would > just listen for TAP enable events. I was thinking the same thing. Cheers, Zach _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
