From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J26yY-0002aw-Gx for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:24:50 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J26yT-0002ZA-PE for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:24:49 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J26yT-0002Z7-JR for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:24:45 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J26yT-00044l-60 for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:24:45 -0500 Date: Tue, 11 Dec 2007 15:24:41 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API Message-ID: <20071211152441.GF17368@redhat.com> References: <475E5403.2000705@bellard.org> <1197364997.4242.10.camel@frecb07144> <475E617D.6090702@qumranet.com> <475EA3F4.50802@codemonkey.ws> <475EAA1F.7050708@eclis.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <475EAA1F.7050708@eclis.ch> Content-Transfer-Encoding: quoted-printable 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 04:17:51PM +0100, Jean-Christian de Rivaz wrote: > Anthony Liguori a =E9crit : > > The main objection I have to dbus is that it's very heavy weight. I= t > >implies a rather fat infrastructure and it not very suitable for=20 > >embedding. QEMU has very few dependencies and that is a strength ATM.= =20 > >People interested in embedding QEMU still want a good management=20 > >interface so enhancing the monitor seems more preferable to me than=20 > >adding a dbus dependency. >=20 > I must object again that. >=20 > I use D-Bus on a very small processor (Analog Devices Blackfin BF-537)=20 > and it work very well. The library is around 200k on the target: this i= s=20 > very supportable for embedded device, especially when you take in=20 > account all the simplifications it allow in the code of each=20 > applications. The D-Bus library have very few and simple dependency. >=20 > D-Bus is a growing standard for the communication between applications.= =20 > I expect that sooner or later, QEMU will be a D-Bus service. A DBus service for controlling QEMU, does not imply that QEMU needs to us= e DBus. It is perfectly possible to write DBus services for managing QEMU outside of the QEMU process. I've written 2 myself - the first exposed a DBus service for managing a collection of VMs, and communicated with QEMU via its monitor. The second, simply exposed the libvirt API over DBus which allows managing of QEMU, Xen, KVM, etc via the same interface. Embedding DBus within QEMU is flawed because it neccessarily restricts yo= u to only managing a single VM, and does not provide you any management=20 capabilities when QEMU is not running. Dan. --=20 |=3D- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 24= 96 -=3D| |=3D- Perl modules: http://search.cpan.org/~danberr/ = -=3D| |=3D- Projects: http://freshmeat.net/~danielpb/ = -=3D| |=3D- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 950= 5 -=3D|=20