Hi all,
I used exclamation points in $SUBJECT, because these suggestions will
have drastic user-visible impact -- though the effects can be mitigated.
All of the work done that I have done recently on the command handling
system has established a foundation for migrating the script language to
use more dynamic command handling.
For example, we have a "$CHIPNAME.cpu" command for each target today,
and recent patches have cloned their old top-level commands under it.
With a little bit of work, those commands should actually work as
expected in their new location (i.e. they still behave as top-level
commands), and they could be retired from the top-level namespace.
Further restructuring may be necessary to reach an ideal language form,
but the system has the ability to manage these sort of tricks now.
This will prevent commands from being run in an unsuitable context,
improve the help/usage output, and generally improve the quality of the
command language. The implementation can be done in the order of steps
listed, allowing scripts to migrate from the old to new schemes.
A 'command deprecated [on|warn|off]' command could be added to set
whether deprecated commands should be registered at all (for testing or
aiding with migration), with the intermediate setting that urges users
to upgrade to the new syntax as soon as possible. The default would be
'on' until the new command language is done, then we'd set it to 'warn'.
Finally, we can turn it 'off' for 1.0, or at the end each successive
major release cycle.
The same approach can be taken with the JTAG interface (to allow
supporting multiple interfaces from within one OpenOCD instance), the
flash banks and NAND devices (to group their sub-commands similar), and
the PLD devices as well.
Finally, would it be logical to create the dynamic flash banks commands
as subcommands of their relevant target?
foo.cpu flash bank bank0 ..... # but no <target> arg anymore
foo.cpu bank0 info # presently, it's 'flash info bank0'
Any other ideas worth considering along these same lines? Leaving such
details of the new command structure aside, what do you think about the
strategic plan of action that I have presented herein?
Cheers,
Zach
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
