> All we need to do is accept the SVF names when > we're reading SVF files. Are you saying that > the current code does not do that?? When I was implementing SVF support, the tap_name was not compatible. As I know, the tap_name has changed for some times, so I'm not sure whether it will change again. Rather than follow the change, I implement a privite tap_name.
2009/10/24, David Brownell <[email protected]>: > On Friday 23 October 2009, simon qian wrote: >> If using tap_state_by_name, it MUST be totally compatible with the SVF >> specification(previous version is not match, so I add a private version). >> Otherwise, a change to the global name of state will affact svf >> implementation. > > All we need to do is accept the SVF names when > we're reading SVF files. Are you saying that > the current code does not do that?? > > Changing state names is not something to be done > lightly in any case; it'd break more than SVF. > The comment by the name table highlights that. > > Note that patch #2 moves away from that notion > of "the" global name of a state ... we'll only > use one name for output (almost exclusively for > debug), but can accept multiple names on input. > > Me, I'd be content with only using SVF names. > But there may be people with other preferences > We could _now_ abet such models, not that I'd > encourage it. :) > > - Dave > > > -- Best Regards, SimonQian http://www.SimonQian.com _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
