From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J26Xg-0000ri-0P for qemu-devel@nongnu.org; Tue, 11 Dec 2007 09:57:04 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J26Xd-0000pT-TT for qemu-devel@nongnu.org; Tue, 11 Dec 2007 09:57:03 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J26Xd-0000pK-Nm for qemu-devel@nongnu.org; Tue, 11 Dec 2007 09:57:01 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J26Xc-0006eB-Uv for qemu-devel@nongnu.org; Tue, 11 Dec 2007 09:57:01 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id lBBEux6f020430 for ; Tue, 11 Dec 2007 09:56:59 -0500 Received: from file.surrey.redhat.com (file.fab.redhat.com [10.33.63.6]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lBBEuxbn022872 for ; Tue, 11 Dec 2007 09:56:59 -0500 Received: (from berrange@localhost) by file.surrey.redhat.com (8.13.1/8.13.1/Submit) id lBBEuwMi027425 for qemu-devel@nongnu.org; Tue, 11 Dec 2007 14:56:58 GMT Date: Tue, 11 Dec 2007 14:56:58 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API Message-ID: <20071211145658.GB17368@redhat.com> References: <475E5403.2000705@bellard.org> <475E6F02.9000302@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475E6F02.9000302@qumranet.com> Reply-To: "Daniel P. Berrange" , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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 -=|