Re: [Qemu-devel] [RFC] New API for asynchronous monitor commands

[Luiz Capitulino <lcapitulino@redhat.com>]

On Sun, 24 Jan 2010 08:01:28 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 01/24/2010 04:59 AM, Avi Kivity wrote:
> > On 01/22/2010 09:03 PM, Adam Litke wrote:
> >>
> >> +static void do_async_cmd_handler(Monitor *mon, const mon_cmd_t *cmd,
> >> +                                 const QDict *params)
> >> +{
> >> +    if (monitor_ctrl_mode(mon)) {
> >> +        cmd->mhandler.cmd_async(mon, params, qmp_monitor_complete, 
> >> mon);
> >> +    } else {
> >> +        int ret;
> >> +
> >> +        UserQMPCompletionData *cb_data = qemu_malloc(sizeof(*cb_data));
> >> +        cb_data->mon = mon;
> >> +        cb_data->user_print = cmd->user_print;
> >> +        monitor_suspend(mon);
> >> +        ret = cmd->mhandler.cmd_async(mon, params,
> >> +                                      user_monitor_complete, cb_data);
> >> +        if (ret<  0) {
> >> +            monitor_resume(mon);
> >> +            qemu_free(cb_data);
> >> +        }
> >> +    }
> >> +}
> >
> > Instead of sending opaques everywhere (and having them correspond to 
> > different types in different cases), I would prefer it if the handle 
> > always accepted an AsyncCommandCompletion *.  That makes it easier to 
> > follow the code, since there are no opaques you have to guess the true 
> > type of.
> 
> I agree with you in principle but the model of passing (function 
> pointer, opaque) is pervasive within QEMU.  I'd prefer consistency here 
> and if we want to switch to something more like a function object, we do 
> it globally.

 We could start doing it in the Monitor, could even serve as an example
for other subsystems.