From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuEsV-0002E7-1I for qemu-devel@nongnu.org; Tue, 23 Mar 2010 20:55:23 -0400 Received: from [140.186.70.92] (port=46451 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuEsT-0002DE-Oy for qemu-devel@nongnu.org; Tue, 23 Mar 2010 20:55:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuEsQ-00035M-VN for qemu-devel@nongnu.org; Tue, 23 Mar 2010 20:55:20 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:38715) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuEsQ-00035E-Sd for qemu-devel@nongnu.org; Tue, 23 Mar 2010 20:55:18 -0400 Received: by gwb11 with SMTP id 11so2218844gwb.4 for ; Tue, 23 Mar 2010 17:55:18 -0700 (PDT) Message-ID: <4BA962F3.1020107@codemonkey.ws> Date: Tue, 23 Mar 2010 19:55:15 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt References: <4BA7C40C.2040505@codemonkey.ws> <20100322201003.GC28709@redhat.com> <4BA7E5E1.1010404@codemonkey.ws> <20100323232531.GE20130@shareable.org> In-Reply-To: <20100323232531.GE20130@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: "libvir-list@redhat.com" , Alexander Graf , qemu-devel On 03/23/2010 06:25 PM, Jamie Lokier wrote: > Alexander Graf wrote: > >> I don't see why we shouldn't be able to automatically generate >> libqemu.so. We have the *.hx files that describe the syntax of >> parameters plus list all available options / commands. I'm not sure >> how exactly QMP works, but having a generic QMP command to list all >> available options would be handy too. >> >> By then we could automate most of the library, making the glueing >> really easy. If libvirt doesn't properly link against libqemu anymore >> we also know why: The ABI changed. >> > I'm thinking most potential uses of the binary API, other than C > programmers, would be happier with a D-Bus version generated from > those same *.hx files. Because then it's easy to call the API from > Python, Perl, even shell, etc. Whereas libqemu.so would be relatively > difficult to use from those languages. > My thinking with respect to libqemu.so is that it should be mostly autogenerated. QMP supports introspection, we should be able to generate an idl description of QMP via introspection and then build all of the function stubs from that idl. Then there is no opportunity for libqemu to be out of date. All we really need to write for libqemu is some core bits to deal with transport specific issues. > (Aside: I don't particularly like D-Bus. But it does seem to work > for this sort of thing.) > I don't think d-bus is a good fit as a core qemu service. It's not commonly used on other platform and it introduces quite a bit of overhead for non-Unix platforms. But that certainly doesn't mean that a d-bus service implemented on top of libqemu (even autogenerated from our IDL) would be a bad project. Regards, Anthony Liguori > -- Jamie >