From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJTRM-0006t7-9O for qemu-devel@nongnu.org; Wed, 24 Jun 2009 10:27:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJTRG-0006pY-Ks for qemu-devel@nongnu.org; Wed, 24 Jun 2009 10:27:07 -0400 Received: from [199.232.76.173] (port=48166 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJTRG-0006pV-Gl for qemu-devel@nongnu.org; Wed, 24 Jun 2009 10:27:02 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:2449) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJTRG-0001XZ-2o for qemu-devel@nongnu.org; Wed, 24 Jun 2009 10:27:02 -0400 Message-ID: <4A4238DA.2030609@eu.citrix.com> Date: Wed, 24 Jun 2009 15:31:54 +0100 From: Stefano Stabellini MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file References: <4A40FFB0.2070905@redhat.com> <4A411FC5.7050701@us.ibm.com> <4A412339.5000109@redhat.com> <4A412659.1080803@us.ibm.com> <20090623220204.GA5612@snarc.org> <4A415C30.7030301@us.ibm.com> <20090624010108.GA6537@snarc.org> <20090624115537.GA24320@taoand.xen.fishsoupisgoodforyou.com> <20090624120958.GD28256@redhat.com> <20090624123212.GB24320@taoand.xen.fishsoupisgoodforyou.com> <20090624125441.GE28256@redhat.com> In-Reply-To: <20090624125441.GE28256@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: James McKenzie , "qemu-devel@nongnu.org" Daniel P. Berrange wrote: > On Wed, Jun 24, 2009 at 01:32:12PM +0100, James wrote: >>> It depends what you mean by 'dbus' here. I don't think managing QEMU over >>> the dbus bus provides the right architecture - I don't think you want >>> every QEMU appearing on the bus. 5B You could do direct peer-to-peer comms >>> so you're just using libdbus for message encapsulation / processing, but >>> there's not really much above XDR. XDR is nice because its a portable >>> library that works on any OS, including OS-X and WIndows, and solely >>> concerns itself with data encoding, not data transport. >> That leaves the rendezvous, and security issues to be re-invented wheels, >> you could use SUNRPC and XDR. That has an excellent IDL. >> >> I don't see why you wouldn't want it on the 'bus', and more than you'd want it >> bound to a tcp port on localhost. It would make things a lot simpler: something >> like a little command line utility to connect a CDROM or ISO image to a Qemu >> instance which would be identified by some uuid or name would be very easy to >> implement. > > This is exactly why I don't want it on the bus. I don't think the monitor > interface is the general end-developer/user administrative interface. It > is a control channel by which a mgmt tool will control QEMU, with the mgmt > tool providing the end-developer/user admin interface. If someone wants > to write a management app that controls QEMU instances and exposes an > API on dbus that's fine, but the individual QEMU instances should not be > directly exposed for use. > Why qemu shouldn't provide a monitor interface on dbus? The mgmt tool could still control qemu and provide the end-developer/user admin interface anyway.