Message ID | 26ecfe2b5f2e2eb9d720b6d3d34a78019ad24f80.1276641524.git.jan.kiszka@web.de |
---|---|
State | New |
Headers | show |
Jan Kiszka <jan.kiszka@web.de> writes: > From: Jan Kiszka <jan.kiszka@siemens.com> > > As we may want to shrink or enhance the argument set used for monitor > command in HMP mode, add a separate, optional argument string for that > case. When an HMP request is parsed, this argument string, if available, > takes precedence over the standard string. > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> args_type strings are such a crude tool... I fear having two of them just breeds inconsistencies. There's a big difference between QMP and HMP: QMP has only named parameters, HMP only positional parameters (type 'O' provides named options within a positional parameter). I figure the proper way to deal with this is to define QMP parameters in a data structure (we need that for self-documentation anyway), then define a mapping from HMP positional parameters to QMP named parameters.
diff --git a/monitor.c b/monitor.c index f535c56..7139c4e 100644 --- a/monitor.c +++ b/monitor.c @@ -108,6 +108,7 @@ typedef struct mon_cmd_t { const char *params; const char *help; void (*user_print)(Monitor *mon, const QObject *data); + const char *user_args_type; union { void (*info)(Monitor *mon); void (*info_new)(Monitor *mon, QObject **ret_data); @@ -3310,7 +3311,7 @@ static const mon_cmd_t *monitor_parse_command(Monitor *mon, } /* parse the parameters */ - typestr = cmd->args_type; + typestr = cmd->user_args_type ? : cmd->args_type; for(;;) { typestr = key_get_info(typestr, &key); if (!typestr) @@ -4040,7 +4041,7 @@ static void monitor_find_completion(const char *cmdline) goto cleanup; } - ptype = next_arg_type(cmd->args_type); + ptype = next_arg_type(cmd->user_args_type ? : cmd->args_type); for(i = 0; i < nb_args - 2; i++) { if (*ptype != '\0') { ptype = next_arg_type(ptype);