[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

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 (X11/20071022)

Avi Kivity wrote:
Fabrice Bellard wrote:

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.


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]