Revision 940cc30d
| ID | 940cc30d0d456781adcc48bf9f8c5582026d7983 |
New API for asynchronous monitor commands
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.
Signed-off-by: Adam Litke <agl@us.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Files
- added
- modified
- copied
- renamed
- deleted