|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API |
Date: | Tue, 11 Dec 2007 08:43:39 -0600 |
User-agent: | Thunderbird 2.0.0.6 (X11/20071022) |
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 inThe other two things to add to the monitor are support for multiple simultaneous connections and some sort of select command.
Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |