From: Luiz Capitulino <lcapitulino@redhat.com>
To: Adam Litke <agl@us.ibm.com>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [RFC] New API for asynchronous monitor commands
Date: Mon, 25 Jan 2010 11:08:03 -0200 [thread overview]
Message-ID: <20100125110803.3841605a@doriath> (raw)
In-Reply-To: <1264187031.2861.13.camel@aglitke>
On Fri, 22 Jan 2010 13:03:51 -0600
Adam Litke <agl@us.ibm.com> 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.
The QMPCompletion callback is called when the asynchronous event happens,
by the function handling it, right?
> 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.
I like the patch, but I don't think it's a good idea to use this in
synchronous commands as they will have to call QMPCompletion (not to
mention unneeded suspend/resume calls).
Also, better to call it MonitorCompletion as this is not only about
QMP.
More comments follow.
> 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
>
> diff --git a/monitor.c b/monitor.c
> index cadf422..c0d0fa9 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -76,6 +76,12 @@
> *
> */
>
> +typedef struct UserQMPCompletionData UserQMPCompletionData;
> +struct UserQMPCompletionData {
> + Monitor *mon;
> + void (*user_print)(Monitor *mon, const QObject *data);
> +};
> +
> typedef struct mon_cmd_t {
> const char *name;
> const char *args_type;
> @@ -85,11 +91,19 @@ typedef struct mon_cmd_t {
> union {
> void (*info)(Monitor *mon);
> void (*info_new)(Monitor *mon, QObject **ret_data);
> + int (*info_async)(Monitor *mon, QMPCompletion *cb, void *opaque);
> void (*cmd)(Monitor *mon, const QDict *qdict);
> void (*cmd_new)(Monitor *mon, const QDict *params, QObject **ret_data);
> + int (*cmd_async)(Monitor *mon, const QDict *params,
> + QMPCompletion *cb, void *opaque);
> } mhandler;
> + int async;
> } mon_cmd_t;
Is 'async' really needed, can't use 'info_async' or 'cmd_async'?
> +static void do_async_info_handler(Monitor *mon, const mon_cmd_t *cmd);
> +static void do_async_cmd_handler(Monitor *mon, const mon_cmd_t *cmd,
> + const QDict *params);
> +
Isn't it possible to avoid this forward declarations?
> /* file descriptors passed via SCM_RIGHTS */
> typedef struct mon_fd_t mon_fd_t;
> struct mon_fd_t {
> @@ -255,6 +269,11 @@ static inline int monitor_handler_ported(const mon_cmd_t *cmd)
> return cmd->user_print != NULL;
> }
>
> +static inline bool monitor_handler_is_async(const mon_cmd_t *cmd)
> +{
> + return cmd->async != 0;
> +}
> +
> static inline int monitor_has_error(const Monitor *mon)
> {
> return mon->error != NULL;
> @@ -453,6 +472,23 @@ static void do_commit(Monitor *mon, const QDict *qdict)
> }
> }
>
> +static void user_monitor_complete(void *opaque, QObject *ret_data)
> +{
> + UserQMPCompletionData *data = (UserQMPCompletionData *)opaque;
> +
> + if (ret_data) {
> + data->user_print(data->mon, ret_data);
> + }
> + monitor_resume(data->mon);
> + qemu_free(data);
> +}
MonitorCompletionData?
> +
> +static void qmp_monitor_complete(void *opaque, QObject *ret_data)
> +{
> + Monitor *mon = (Monitor *)opaque;
> + monitor_protocol_emitter(mon, ret_data);
> +}
You should free ret_data as well with:
qobject_decref(ret_data);
Also, you can pass 'opaque' directly to monitor_protocol_emitter().
> +
> static void do_info(Monitor *mon, const QDict *qdict, QObject **ret_data)
> {
> const mon_cmd_t *cmd;
> @@ -476,7 +512,15 @@ static void do_info(Monitor *mon, const QDict *qdict, QObject **ret_data)
> goto help;
> }
>
> - if (monitor_handler_ported(cmd)) {
> + if (monitor_handler_is_async(cmd)) {
> + do_async_info_handler(mon, cmd);
> + /*
> + * Indicate that this command is asynchronous and will not return any
> + * date (not even empty). Instead, the data will be returned via a
> + * completion callback.
s/date/data
> + */
> + *ret_data = qobject_from_jsonf("{ 'async': 'return' }");
This is obviously only used internally, right? Sure it's _impossible_
to conflict with handlers' returned keys?
Anyway, I think it's a good idea to have a standard for internal
keys. Maybe something like: "__mon_".
> + } else if (monitor_handler_ported(cmd)) {
> cmd->mhandler.info_new(mon, ret_data);
>
> if (!monitor_ctrl_mode(mon)) {
> @@ -3612,6 +3656,11 @@ static void monitor_print_error(Monitor *mon)
> mon->error = NULL;
> }
>
> +static int is_async_return(const QObject *data)
> +{
> + return data && qdict_haskey(qobject_to_qdict(data), "async");
> +}
> +
> static void monitor_call_handler(Monitor *mon, const mon_cmd_t *cmd,
> const QDict *params)
> {
> @@ -3619,7 +3668,15 @@ static void monitor_call_handler(Monitor *mon, const mon_cmd_t *cmd,
>
> cmd->mhandler.cmd_new(mon, params, &data);
>
> - if (monitor_ctrl_mode(mon)) {
> + if (is_async_return(data)) {
> + /*
> + * Asynchronous commands have no initial return data but they can
> + * generate errors. Data is returned via the async completion handler.
> + */
> + if (monitor_ctrl_mode(mon) && monitor_has_error(mon)) {
> + monitor_protocol_emitter(mon, NULL);
> + }
> + } else if (monitor_ctrl_mode(mon)) {
> /* Monitor Protocol */
> monitor_protocol_emitter(mon, data);
> } else {
> @@ -3631,6 +3688,46 @@ static void monitor_call_handler(Monitor *mon, const mon_cmd_t *cmd,
> qobject_decref(data);
> }
>
> +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);
> + }
> + }
> +}
I'm trying to decouple QMP and user Monitor functions so that in the
near future we can have four modules: monitor.c (common code),
monitor_qmp.c, monitor_user.c and monitor_handlers.c.
So, maybe it's better to split this.
> +
> +static void do_async_info_handler(Monitor *mon, const mon_cmd_t *cmd)
> +{
> + if (monitor_ctrl_mode(mon)) {
> + cmd->mhandler.info_async(mon, 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.info_async(mon, user_monitor_complete, cb_data);
> + if (ret < 0) {
> + monitor_resume(mon);
> + qemu_free(cb_data);
> + }
> + }
> +}
> +
> static void handle_user_command(Monitor *mon, const char *cmdline)
> {
> QDict *qdict;
> @@ -3644,7 +3741,9 @@ static void handle_user_command(Monitor *mon, const char *cmdline)
>
> qemu_errors_to_mon(mon);
>
> - if (monitor_handler_ported(cmd)) {
> + if (monitor_handler_is_async(cmd)) {
> + do_async_cmd_handler(mon, cmd, qdict);
> + } else if (monitor_handler_ported(cmd)) {
> monitor_call_handler(mon, cmd, qdict);
> } else {
> cmd->mhandler.cmd(mon, qdict);
> @@ -4106,7 +4205,11 @@ static void handle_qmp_command(JSONMessageParser *parser, QList *tokens)
> goto err_out;
> }
>
> - monitor_call_handler(mon, cmd, args);
> + if (monitor_handler_is_async(cmd)) {
> + do_async_cmd_handler(mon, cmd, args);
> + } else {
> + monitor_call_handler(mon, cmd, args);
> + }
> goto out;
>
> err_input:
> diff --git a/monitor.h b/monitor.h
> index 2da30e8..366b423 100644
> --- a/monitor.h
> +++ b/monitor.h
> @@ -44,4 +44,6 @@ void monitor_printf(Monitor *mon, const char *fmt, ...)
> void monitor_print_filename(Monitor *mon, const char *filename);
> void monitor_flush(Monitor *mon);
>
> +typedef void (QMPCompletion)(void *opaque, QObject *ret_data);
> +
> #endif /* !MONITOR_H */
>
>
next prev parent reply other threads:[~2010-01-25 13:08 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
2010-01-24 14:19 ` Avi Kivity
2010-01-25 13:12 ` Luiz Capitulino
2010-01-25 13:08 ` Luiz Capitulino [this message]
2010-01-25 14:00 ` [Qemu-devel] " 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=20100125110803.3841605a@doriath \
--to=lcapitulino@redhat.com \
--cc=agl@us.ibm.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).