[Openocd-development] [PATCH 03/12] arm-jtag-ew: use register_commands()
Uses register_commands() with command registration array.
Signed-off-by: Zachary T Welch
---
src/jtag/arm-jtag-ew.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/jtag/arm-jtag-ew.c b/src/jtag/arm-jtag-ew.c
index 82ff2a0..5363ae8 100644
--- a/src/jtag/arm-jtag-ew.c
+++ b/src/jtag/arm-jtag-ew.c
@@ -501,12 +501,20 @@ COMMAND_HANDLER(armjtagew_handle_armjtagew_info_command)
return ERROR_OK;
}
+static const struct command_registration armjtagew_command_handlers[] = {
+ {
+ .name = "armjtagew_info",
+ .handler = &armjtagew_handle_armjtagew_info_command,
+ .mode = COMMAND_EXEC,
+ .help = "query armjtagew info",
+ },
+ };
+
static int armjtagew_register_commands(struct command_context *cmd_ctx)
{
- COMMAND_REGISTER(cmd_ctx, NULL, "armjtagew_info",
- &armjtagew_handle_armjtagew_info_command, COMMAND_EXEC,
- "query armjtagew info");
- return ERROR_OK;
+ return register_commands(cmd_ctx, NULL,
+ ARRAY_SIZE(armjtagew_command_handlers),
+ armjtagew_command_handlers);
}
struct jtag_interface armjtagew_interface = {
--
1.6.4.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 03/12] arm-jtag-ew: use register_commands()
Why is a table better than a fn call for registering commands? -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 03/12] arm-jtag-ew: use register_commands()
On Sat, 2009-11-21 at 21:31 +0100, Øyvind Harboe wrote:
> Why is a table better than a fn call for registering commands?
It's harder to screw up with the new way of doing things, as the
registration parameters are more explicit. It also eliminates a lot of
redundant calls to register_command{,s} with a single call in tcl.c.
In short, it's more readable and produces slightly better binaries.
More importantly, the first patches in the previous series allowed the
registration parameters to be extended without disrupting the existing
registration callers. That series then added aded the 'usage' command,
and subsequent patches begin to split the help text out. Other
extensions will be much easier -- and can be done in stages -- by using
a table instead of a function.
For the target and flash, we'll need further patches to extend the
registration capabilities to allow "inheriting" commands. An arm966e
might register its own commands, but it also needs to register the
arm9tdmi, arm7_9_common, arm, and etm groups of commands as well.
I have these changes underway in my local tree, but each of my current
series offered reasonable milestones that showed the intended benefits.
There are some other minor features that need to be added to allow this
transformation to take place throughout the tree, but the result should
be a more openly transparent and extensible command handling system
(that eliminates redundancy when coding things up). Naturally, I'll
update the command API documentation in the manual once I am done with
these changes throughout the tree.
--Z
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
