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

["Daniel P. Berrange" <berrange@redhat.com>]

On Tue, Dec 11, 2007 at 01:05:38PM +0200, 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.

To be honest this is overkill. IMHO, there should simply be a client side
'libqemumonitor.so' which provides a formal C API for applications to use.
This C api would then talk to the QEMU monitor, thus isolating all the
string parsing & formatting in one place. Behind the scenes I could imagine
dropping in an alternative QEMU monitor impl which used an XDR serialization
format for the args & reply to avoid the string parsing/formatting, but this
is a minor detail, compared to the big picture, which is that applications
would benefit from a simply C api implementing the monitor commands. I'd
be interested in using such an API in libvirt, since I could remove the 
string parsing/formatting code I currently have. Having libvirt drop a
custom .so into the QEMU process just feels horribly wrong.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|