[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] New API for asynchronous monitor commands
From: |
Luiz Capitulino |
Subject: |
Re: [Qemu-devel] [RFC] New API for asynchronous monitor commands |
Date: |
Mon, 25 Jan 2010 11:12:19 -0200 |
On Sun, 24 Jan 2010 08:01:28 -0600
Anthony Liguori <address@hidden> 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.