>> cmd_ctx contains current target today. The above definitively moves
>> current target out of cmd_ctx. OK by me, but we need backwards
>> compatibility.
>>
>
> No it does not. The idea is the "command private" variable holds the
> 'current target pointer".
>
> I do not see that something is breaking with the above.
Me neither.
What I meant was that the new Tcl commands will not rely on
cmd_ctx current target, but rather use the oo-like syntax.
>> Of course without breaking the target_script command. :-)
>>
>
> How do you think this would break the existing target script. I mean to
> specifically *DELETE* the "target_X_NAME" support and no longer support that
> at all.
The "target_script" command must be supported, it's *old* :-)
> Or is this something that needs to exist? I do not think so. It has had less
> then 1month in the wild.
The new target_N_event proc's you can replace with something else,
they are work in progress. No need to retain backwards compatibilty there.
>> I consider the current target functionality of mww part of the Telnet
>> user interface.
>>
>
> And "mww" will remain, a 1st class command - that effects the *CURRENT*
> target. No intention of removing it. It should 100% stay there.
Goody.
>
> However, if you prefix "mww" with TARGETNAME - it effects only the
> specified target and does not modify the current target.
> In theory Sort of like this... - but not implemented like this.
>
> push current target.
> set target to NAME.
> execute mww ADDRESS DATA
> pop target
As long as there are no nasty reentrancy in the picture, then this should work.
>> almost *all* use of OpenOCD is single target, so we must not complicate
>> the
>> life of single target users.
>>
>
> Exactly - why "mww" and others will remain as 1st class commands, and not
> become "subcommands".
>
> The idea is PREFIX the command with the target name... and it is target
> specific.
Sounds good.
>>> There is nothing that does: jtag_execute_queue()
>>>
>>
>> This needs a bit of thought:
>>
>> jtag_execute_queue() has a crucial feature: it tells you whether any
>> of the commands
>> in the queue failed.
>>
>
> Simple:
>
> if { catch [jtag -execute-queue] msg } {
> puts "ERROR: $msg"
> }
My thinking was that e.g. drscan would throw this exception and that we didn't
expose execute queue.
Why should expose an asynchronous model for scripting?
It complicates the API.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
