From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NtyjC-0004qW-Ly for qemu-devel@nongnu.org; Tue, 23 Mar 2010 03:40:42 -0400 Received: from [199.232.76.173] (port=39530 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NtyjA-0004pP-AA for qemu-devel@nongnu.org; Tue, 23 Mar 2010 03:40:40 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NtyeJ-00044z-Ib for qemu-devel@nongnu.org; Tue, 23 Mar 2010 03:35:42 -0400 Received: from cantor2.suse.de ([195.135.220.15]:48043 helo=mx2.suse.de) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NtyeJ-00044p-2Q for qemu-devel@nongnu.org; Tue, 23 Mar 2010 03:35:39 -0400 Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Alexander Graf In-Reply-To: <4BA7E5E1.1010404@codemonkey.ws> Date: Tue, 23 Mar 2010 08:35:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BA7C40C.2040505@codemonkey.ws> <20100322201003.GC28709@redhat.com> <4BA7E5E1.1010404@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "libvir-list@redhat.com" , qemu-devel On 22.03.2010, at 22:49, Anthony Liguori wrote: > On 03/22/2010 03:10 PM, Daniel P. Berrange wrote: >>=20 >> =20 >>> What's the feeling about this from the libvirt side of things? Is = there >>> interest in support hypervisor specific interfaces should we be = looking >>> to provide our own management interface for libvirt to consume? >>> =20 >> Adding yet another library in the stack isn't really going to solve = the >> problem from the POV of libvirt users, but rather fork the community >> effort which I imagine we'd all rather avoid. Having to tell people = to >> switch to a different library API to get access to a specific feature >> is a short term win, but with a significant long term cost/burden. = This >> means we really do need to figure out how to better/fully support = QEMU's >> features in libvirt, removing the feature timelag pain. >> =20 >=20 > I think what we need to do is find a way to more tightly integrate the = QEMU and libvirt communities in such a way that when a patch was = submitted against QEMU adding a new feature, we could ask that that = feature was implemented in libvirt. I see two ways to do this. >=20 > One would be for libvirt to have a libvirt.so and libvirt-qemu.so. = The QEMU community would have to be much more heavily involved in = libvirt-qemu.so and it probably suggests that libvirt-qemu.so should = follow our release cycle. libvirt would have to support using either = libvirt.so or libvirt-qemu.so for it's users. >=20 > The alternative would be for the QEMU community to produce a = libqemu.so and for libvirt.so to consume libqemu.so. The libvirt = community ought to be heavily engaged in the development of libqemu.so = and certainly, shared maintainership would be appropriate. A user using = libvirt.so should see guests created with either libqemu.so or = libvirt.so although libqemu.so would provide weaker long term = compatibility guarantees (but more features). 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. All that's needed then is a common Qemu object that libvirt users can = get access to as well. That object is the magic key to all libqemu = functions. If users need functionality not exposed in libvirt, they can = then use libqemu calls directly. If they don't care about all the = awesomeness of libvirt and don't want to be hypervisor agnostic, they = can stick to libqemu completely. Alex=