On 20/01/21 09:03, Markus Armbruster wrote:
The detour should be avoided, because QemuOpts should be avoided. Using the appropriate visitor, we get:char *optarg | | v = qobject_input_visitor_new_str(string, NULL, errp) | visit_type_q_obj_set_action_arg(v, NULL, &arg, errp); v q_obj_set_action_arg arg except visit_type_q_obj_set_action_arg() doesn't exist, because the QAPI type is anonymous. So give it a name: { 'struct: 'Action', 'data': { '*reboot': 'RebootAction', '*shutdown': 'ShutdownAction', '*panic': 'PanicAction', '*watchdog': 'WatchdogAction' } } { 'command': 'set-action', 'data': 'Action', 'allow-preconfig': true } char *optarg | | v = qobject_input_visitor_new_str(string, NULL, errp) | visit_type_Action(v, NULL, &arg, errp); v Action act To avoid having to pass the members of Action to qmp_set_action(), throw in 'boxed': true, so you can simply call qmp_set_action(&act, errp).
Ok, so the idea of a 1:1 CLI<->QMP mapping is good, the implementation is bad. The reason it was done with QemuOpts was mostly to have "-action help" for free. Something to remember when working on autogenerated boilerplate.
Paolo
