[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