qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Avi Kivity <avi@redhat.com>
Cc: Luiz Capitulino <lcapitulino@redhat.com>,
	qemu-devel@nongnu.org, Adam Litke <agl@us.ibm.com>
Subject: Re: [Qemu-devel] [RFC] New API for asynchronous monitor commands
Date: Sun, 24 Jan 2010 08:01:28 -0600	[thread overview]
Message-ID: <4B5C52B8.6050900@codemonkey.ws> (raw)
In-Reply-To: <4B5C2811.8060408@redhat.com>

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.

Regards,

Anthony Liguori

>
> Somewhat related, we could have mon->suspend() and mon->resume() 
> callbacks to avoid the check for monitor_ctrl_mode().
>

  reply	other threads:[~2010-01-24 14:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-22 19:03 [Qemu-devel] [RFC] New API for asynchronous monitor commands Adam Litke
2010-01-22 23:17 ` [Qemu-devel] " Anthony Liguori
2010-01-24 10:55   ` Avi Kivity
2010-01-25 13:10   ` Luiz Capitulino
2010-01-24 10:59 ` [Qemu-devel] " Avi Kivity
2010-01-24 14:01   ` Anthony Liguori [this message]
2010-01-24 14:19     ` Avi Kivity
2010-01-25 13:12     ` Luiz Capitulino
2010-01-25 13:08 ` [Qemu-devel] " Luiz Capitulino
2010-01-25 14:00   ` Adam Litke
2010-01-25 15:02     ` Luiz Capitulino
2010-01-25 14:15   ` Anthony Liguori
2010-01-25 14:51     ` Luiz Capitulino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B5C52B8.6050900@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=agl@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).