Avi Kivity wrote:
Fabrice Bellard wrote:
Hi,
At this point I am not interested in integrating it into QEMU as it
is one more API level to maintain in addition to the command line
monitor. However, I can change my mind if several projects insists to
have a similar interface.
I think that many projects now want to control qemu programatically.
The monitor is not a good interface since it is text-based, hard to
parse, and liable to change without notice when new features are
added. However, I agree that having many similar constructs is not a
good thing, and that we should retain the monitor for non-programmatic
control.
What do you say to implementing the qemu interface as a plugin API,
and implementing the monitor on top of this API? e.g.:
qemu loads /usr/local/lib/qemu/libmonitor.so, which uses the API to
export the good old qemu monitor interface. If it finds
/usr/local/lib/qemu/libdbus.so, it loads an additional dbus
interface. If libvirt wants to drop a libvirtapi.so into that
directory, it can control qemu through that.
Why not just improve the monitor interface? Half the internet is based
on human-readable text protocols.
I don't think there would be a lot of objections to adding a status
field with each monitor command. It could even be done in a way that
was backwards compatible. For instance:
(qemu) info kqemu
kqemu support is not compiled in
(qemu) verbosity status
(qemu) info kqemu
-38: kqemu support is not compiled in
The other two things to add to the monitor are support for multiple
simultaneous connections and some sort of select command.
Regards,
Anthony Liguori