From: Anthony Liguori <anthony@codemonkey.ws>
To: Adam Litke <agl@us.ibm.com>
Cc: Markus Armbruster <armbru@redhat.com>,
Avi Kivity <avi@redhat.com>,
qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>
Subject: [Qemu-devel] Re: [RFC] New API for asynchronous monitor commands
Date: Fri, 22 Jan 2010 17:17:27 -0600 [thread overview]
Message-ID: <4B5A3207.5030105@codemonkey.ws> (raw)
In-Reply-To: <1264187031.2861.13.camel@aglitke>
On 01/22/2010 01:03 PM, Adam Litke wrote:
> Qemu has a number of commands that can operate asynchronously (savevm, migrate,
> etc) and it will be getting more. For these commands, the user monitor needs
> to be suspended, but QMP monitors could continue to to accept other commands.
> This patch introduces a new command API that isolates the details of handling
> different monitor types from the actual command execution.
>
> A monitor command can use this API by implementing the mhandler.cmd_async
> handler (or info_async if appropriate). This function is responsible for
> submitting the command and does not return any data although it may raise
> errors. When the command completes, the QMPCompletion callback should be
> invoked with its opaque data and the command result.
>
> The process for submitting and completing an asynchronous command is different
> for QMP and user monitors. A user monitor must be suspended at submit time and
> resumed at completion time. The user_print() function must be passed to the
> QMPCompletion callback so the result can be displayed properly. QMP monitors
> are simpler. No submit time setup is required. When the command completes,
> monitor_protocol_emitter() writes the result in JSON format.
>
> This API can also be used to implement synchronous commands. In this case, the
> cmd_async handler should immediately call the QMPCompletion callback. It is my
> hope that this new interface will work for all commands, leading to a
> drastically simplified monitor.c once all commands are ported.
>
> Thanks to Anthony for helping me out with the initial design.
>
> Signed-off-by: Adam Litke<agl@us.ibm.com>
> To: Anthony Liguori<anthony@codemonkey.ws>
> cc: Luiz Capitulino<lcapitulino@redhat.com>
> Cc: qemu-devel@nongnu.org
>
I like this a lot and I'd like to see us remove cmd_new in place of
cmd_async. The conversion is pretty easy since we just have to add a
cb(ret_data) to the end of synchronous functions.
Luiz/Markus/Avi, what do ya'll think?
Regards,
Anthony Liguori
next prev parent reply other threads:[~2010-01-22 23:17 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 ` Anthony Liguori [this message]
2010-01-24 10:55 ` [Qemu-devel] " 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
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=4B5A3207.5030105@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=agl@us.ibm.com \
--cc=armbru@redhat.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).