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

[Anthony Liguori <anthony@codemonkey.ws>]

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