From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuNVP-0004oe-1b for qemu-devel@nongnu.org; Wed, 24 Mar 2010 06:08:07 -0400 Received: from [140.186.70.92] (port=53431 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuNT5-00049R-J5 for qemu-devel@nongnu.org; Wed, 24 Mar 2010 06:08:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuNSY-0005UH-M3 for qemu-devel@nongnu.org; Wed, 24 Mar 2010 06:05:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14283) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuNSY-0005UA-Et for qemu-devel@nongnu.org; Wed, 24 Mar 2010 06:05:10 -0400 From: Markus Armbruster 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> <4BA962F3.1020107@codemonkey.ws> Date: Wed, 24 Mar 2010 11:05:00 +0100 In-Reply-To: <4BA962F3.1020107@codemonkey.ws> (Anthony Liguori's message of "Tue, 23 Mar 2010 19:55:15 -0500") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "libvir-list@redhat.com" , Alexander Graf , qemu-devel Anthony Liguori writes: > 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. Yes, the plan is to have QMP describe itself. Needs work. >>> 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 can't quite see what such a libqemu would buy us compared to straight QMP. Talking QMP should be easy, provided you got a suitable JSON library. Generating a libqemu.so for (a particular version of) QMP may make talking (that version of) QMP slightly easier in C, by turning a simple text network protocol into a C API. But it's not without drawbacks. The text protocol is designed to be evolvable in backward-compatible ways. For instance, we can new add commands, new optional arguments, and so forth. But you can't add new optional arguments to C functions without changing the API. You can change the function and bump the soname, or you can deprecate the function and add a new one, or you can bypass static typing, e.g. by passing arguments in a dictionary. In the latter case, why not put the command in the dictionary as well, and cut the number of functions from N to 1. Ensured consistency of libqmp and QEMU sounds nice. But it's consistent with a *local* version of QEMU. QMP is a *network* protocol. If your app talks QMP straight, it can handle any remote version it knows all by itself. If you interpose libqmp, you add a dependency: you need a sufficiently current *local* QEMU/libqmp. >> 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. I suspect importing a foreign libqmp.so C API into a non-C language is no easier than using the language's JSON facilities and talk QMP straight, and less flexible. > 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. I can't quite see the utility of that. [D-Bus snipped...]