qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: [Qemu-devel] Re: [RFC] New API for asynchronous monitor commands
Date: Fri, 22 Jan 2010 17:17:27 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

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<address@hidden>
To: Anthony Liguori<address@hidden>
cc: Luiz Capitulino<address@hidden>
Cc: address@hidden

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]