From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nu6eA-0006E2-ER for qemu-devel@nongnu.org; Tue, 23 Mar 2010 12:08:02 -0400 Received: from [199.232.76.173] (port=54382 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nu6e7-00069T-P0 for qemu-devel@nongnu.org; Tue, 23 Mar 2010 12:07:59 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nu6dM-0005H7-Sf for qemu-devel@nongnu.org; Tue, 23 Mar 2010 12:07:14 -0400 Received: from mx20.gnu.org ([199.232.41.8]:32502) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Nu6dI-0005Ek-N2 for qemu-devel@nongnu.org; Tue, 23 Mar 2010 12:07:12 -0400 Received: from mail-pw0-f45.google.com ([209.85.160.45]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nu6co-0005p2-8G for qemu-devel@nongnu.org; Tue, 23 Mar 2010 12:06:38 -0400 Received: by pwi9 with SMTP id 9so4360614pwi.4 for ; Tue, 23 Mar 2010 09:06:34 -0700 (PDT) Message-ID: <4BA8E6FC.9080207@codemonkey.ws> Date: Tue, 23 Mar 2010 11:06:20 -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> <20100323145105.GV16253@redhat.com> <4BA8D8A9.7090308@codemonkey.ws> <201003231557.19474.paul@codesourcery.com> In-Reply-To: <201003231557.19474.paul@codesourcery.com> 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: Paul Brook Cc: "libvir-list@redhat.com" , qemu-devel@nongnu.org On 03/23/2010 10:57 AM, Paul Brook wrote: >>> I think there is a serious divergence of approach there, instanciating >>> API stating 'we are gonna deprecate them sooner or later' tell the >>> application developper 'my time is more important than yours' and not >>> really something I like to carry to the API users. >>> The main goal of libvirt remains to provide APIs needed to unify the >>> development of the virtualization layers. Having APIs which makes >>> sense only for one or 2 virtualization engines is not a problem in >>> itself, it just raises questions about the actual semantic of that API. >>> If that semantic is sound, then I see no reason to not add it, really >>> and we actually often do. >>> >> Yeah, but the problem we're facing is, I want there to be an API added >> to the management layer as part of the feature commit in qemu. If there >> has to be a discussion and decisions about how to model the API, it's >> not going to be successful. >> > I thought the monitor protocol *was* our API. If not, why not? > It is. But our API is missing key components like guest enumeration. So the fundamental topic here is, do we introduce these missing components to allow people to build directly to our interface or do we make use of the functionality that libvirt already provides if they can plumb our API directly to users. Regards, Anthony Liguori > Paul >