On Wed, Jan 14, 2009 at 11:29:38AM +0000, Richard W.M. Jones wrote:
On Wed, Jan 14, 2009 at 04:40:05PM +0530, Amit Shah wrote:
- Have a libqemumonitor.so that will abstract out output from qemu and
provide a machine-readble output for the consumer
Why do we need a C API at all? IMHO it'd be better just to make the
existing qemu monitor output more machine-friendly, meaning consistent
delimiters so that programs can reliably resynchronize with the
output, and consistent guarantees on error messages.
Well if we have async messages over a separate channel, we can already
reliably resynchronize with the output, because QEMU will eventually
produce its '(qemu) ' prompt on a new line. So if something goes wrong
you just need to skip until you find the prompt again. Changing QEMU
monitor prompt will just break all existing libvirt deployments, and
any other programs relying on currently prompt.
IMHO, any libqemumonitor.so should be made to work with current monitor
format as its starting point, and then extend from there, not change
any existing characteristics. This provides forwards & backwards compat
for all apps, albeit at cost of slightly more complex internals for
the libqemumonitor.so - but this complexity will be centralized in one
place instead of all apps using QEMU, so this is still a net win.