From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J274x-0007ps-0g for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:31:27 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J274u-0007oY-Ss for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:31:26 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J274u-0007oV-JK for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:31:24 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J274u-0005Zs-6D for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:31:24 -0500 Date: Tue, 11 Dec 2007 15:31:21 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API Message-ID: <20071211153121.GG17368@redhat.com> References: <475E5403.2000705@bellard.org> <1197364997.4242.10.camel@frecb07144> <475E617D.6090702@qumranet.com> <475EA3F4.50802@codemonkey.ws> <20071211150033.GC17368@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Yuval Kashtan Cc: qemu-devel@nongnu.org On Tue, Dec 11, 2007 at 05:21:08PM +0200, Yuval Kashtan wrote: > As I can see, > There is HUGH interest in management API for QEMU. > seemly, DBus is NOT the right solution for direct integration into QEMU as > it is not cross platform enough, pose extra dependency and (probably) not > suitable for embedded systems. > > Keeping only the "old" monitor interface with no formal interface will make > QEMU harder to integrate with as it requires extra work The monitor does have an initial barrier to entry, but that can be addressed by providing a C API which sends & receives monitor commands. This does not require any intrusive modification of QEMU, at most incremental enhancements to make the monitor more complete. > C API is not a complete solution as it does not define well enough how will > you integrate with QEMU without changing or adding to the source.. > But combined with AVI's idea of some plug-in mechanism, which will use this > C API, it sounds like a complete and valid solution. You are now exposing the internals of QEMU as a stable ABI which has to be maintained indefinittely to avoid breaking these out-of-tree plugins. THis does not sound like a winning solution since it'll dramatically restrict the scope of future development of QEMU code. 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 -=|