From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJS01-0001Ma-MA for qemu-devel@nongnu.org; Wed, 24 Jun 2009 08:54:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJRzw-0001KV-SQ for qemu-devel@nongnu.org; Wed, 24 Jun 2009 08:54:49 -0400 Received: from [199.232.76.173] (port=40969 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJRzw-0001KS-Ki for qemu-devel@nongnu.org; Wed, 24 Jun 2009 08:54:44 -0400 Received: from mx1.redhat.com ([66.187.233.31]:40000) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJRzw-0007K9-6r for qemu-devel@nongnu.org; Wed, 24 Jun 2009 08:54:44 -0400 Date: Wed, 24 Jun 2009 13:54:41 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file Message-ID: <20090624125441.GE28256@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090624123212.GB24320@taoand.xen.fishsoupisgoodforyou.com> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: James Cc: "qemu-devel@nongnu.org" 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. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|