From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJRIl-0002Vt-UD for qemu-devel@nongnu.org; Wed, 24 Jun 2009 08:10:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJRIh-0002R0-9h for qemu-devel@nongnu.org; Wed, 24 Jun 2009 08:10:07 -0400 Received: from [199.232.76.173] (port=49889 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJRIh-0002Qt-2g for qemu-devel@nongnu.org; Wed, 24 Jun 2009 08:10:03 -0400 Received: from mx1.redhat.com ([66.187.233.31]:35427) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJRIg-00012l-N1 for qemu-devel@nongnu.org; Wed, 24 Jun 2009 08:10:02 -0400 Date: Wed, 24 Jun 2009 13:09:58 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file Message-ID: <20090624120958.GD28256@redhat.com> References: <4A40FD1A.1040303@redhat.com> <4A40FE31.2010007@us.ibm.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090624115537.GA24320@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 12:55:37PM +0100, James wrote: > > now providing there was a maintained library out there, would you use it ? > > or do you have more concerns that were unanswered ? > > I have exactly one concern. If Qemu grows an RPC protocol, it will be used > by a large number of other programs to control qemu. This is a good thing. > But it is important that such a system > > 1) either supports some sort of introspection so that the functions and > their arguments can be divined by the external program without knowing > which particular version of qemu it is talking to. > > 2) and/or supports an IDL so that the interface is properly documented in > something other than an under-edited text file. > > > To this end I tentitatively suggest d-bus as a possible choice. It fills 1 and 2 > nicely and also allows each module to have its own interfaces and objects. > The IDL will also generate C bindings for both ends. 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. 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 :|