On Saturday 06 June 2009, Rick Altherr wrote: > Having the target and tap names be the same is _not_ preferable. It > makes the relationship between those two layers very confusing.
Hmm, having them be the same is the convention that's encouraged already, as well as being the one used in every target/*.cfg script I've looked at. And I just grepped ... all the current "target create" commands use $_TARGETNAME for both the target and TAP names. Notice how the "targets" command shows two names, normally the same. If it's confusing (and I wouldn't agree that it is), it's not a new type of confusion. And I would argue that having more than one namespace is itself very confusing... particularly since the current policy more or less hides one of the namespaces. > If you make > the names the same, people get confused when the $(target name) > command isn't available but the TAP has been created. People are always free to be foolish. If "targets" doesn't list the name, there is no target. TAP != target except on very simple systems. Although ... this reminds me how the "scan_chain" command is buried so deeply in the user's guide. I'll send a patch to present it when scan chains are presented ... which will help better distinguish the "list of TAPs" and "list of targets" concepts, by properly presenting both of them. (Though it'd be nice to have tap-list primitives like we have target-list primitives...) > > Which just > > points out another conceptual problem ... either (a) "target create" > > should force target and TAP names to be the same (so "-chain-position" > > becomes redundant), *or* (b) we need a "list enabled taps" primitive. Minor nit: I should have written "mechanism" not primitive. And part of why I think that (a) is preferable is that it would let us avoid creating parallel "$target_name tapisenabled" predicates to match the already-working "jtag tapisenabled $tap_name" one. Another is to avoid the nastiness inherent in the current capability of running "target configure -chain-position foo.bar" *after* the target has been set up. I can't ever see goodness coming from that... That is, it would help keep the layer distinction: there's a TAP layer, and a target layer. TAP operations don't work on targets, and vice versa. (Some TAPs are isomorphic to targets too, and in the simplest systems there may be only one tap == a target.) _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
