[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: Daniel P. Berrange
Subject: Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API
Date: Tue, 11 Dec 2007 14:56:58 +0000
User-agent: Mutt/1.4.1i

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.

|=- 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  -=| 

reply via email to

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