qemu/monitor.h

63 lines
1.6 KiB
C
Raw Normal View History

#ifndef MONITOR_H
#define MONITOR_H
#include "qemu-common.h"
#include "qemu-char.h"
#include "qerror.h"
#include "qdict.h"
#include "block.h"
extern Monitor *cur_mon;
monitor: Separate "default monitor" and "current monitor" cleanly Commits 376253ec..731b0364 introduced global variable cur_mon, which points to the "default monitor" (if any), except during execution of monitor_read() or monitor_control_read() it points to the monitor from which we're reading instead (the "current monitor"). Monitor command handlers run within monitor_read() or monitor_control_read(). Default monitor and current monitor are really separate things, and squashing them together is confusing and error-prone. For instance, usb_host_scan() can run both in "info usbhost" and periodically via usb_host_auto_check(). It prints to cur_mon, which is what we want in the former case: the monitor executing "info usbhost". But since that's the default monitor in the latter case, it periodically spams the default monitor there. A few places use cur_mon to log stuff to the default monitor. If we ever log something while cur_mon points to current monitor instead of default monitor, the log temporarily "jumps" to another monitor. Whether that can or cannot happen isn't always obvious. Maybe logging to the default monitor (which may not even exist) is a bad idea, and we should log to stderr or a logfile instead. But that's outside the scope of this commit. Change cur_mon to point to the current monitor. Create new default_mon to point to the default monitor. Update users of cur_mon accordingly. This fixes the periodical spamming of the default monitor by usb_host_scan(). It also stops "log jumping", should that problem exist.
2010-02-18 13:41:55 +03:00
extern Monitor *default_mon;
/* flags for monitor_init */
#define MONITOR_IS_DEFAULT 0x01
#define MONITOR_USE_READLINE 0x02
#define MONITOR_USE_CONTROL 0x04
#define MONITOR_USE_PRETTY 0x08
/* flags for monitor commands */
#define MONITOR_CMD_ASYNC 0x0001
/* QMP events */
typedef enum MonitorEvent {
QEVENT_SHUTDOWN,
QEVENT_RESET,
QEVENT_POWERDOWN,
QEVENT_STOP,
QEVENT_RESUME,
QEVENT_VNC_CONNECTED,
QEVENT_VNC_INITIALIZED,
QEVENT_VNC_DISCONNECTED,
QEVENT_BLOCK_IO_ERROR,
QEVENT_RTC_CHANGE,
QEVENT_WATCHDOG,
QEVENT_MAX,
} MonitorEvent;
2010-02-11 19:05:43 +03:00
int monitor_cur_is_qmp(void);
void monitor_protocol_event(MonitorEvent event, QObject *data);
void monitor_init(CharDriverState *chr, int flags);
int monitor_suspend(Monitor *mon);
void monitor_resume(Monitor *mon);
int monitor_read_bdrv_key_start(Monitor *mon, BlockDriverState *bs,
BlockDriverCompletionFunc *completion_cb,
void *opaque);
int monitor_get_fd(Monitor *mon, const char *fdname);
void monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
GCC_FMT_ATTR(2, 0);
void monitor_printf(Monitor *mon, const char *fmt, ...) GCC_FMT_ATTR(2, 3);
void monitor_print_filename(Monitor *mon, const char *filename);
void monitor_flush(Monitor *mon);
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>
2010-01-25 21:18:44 +03:00
typedef void (MonitorCompletion)(void *opaque, QObject *ret_data);
void monitor_set_error(Monitor *mon, QError *qerror);
#endif /* !MONITOR_H */