From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nu6lI-0004VW-Vq for qemu-devel@nongnu.org; Tue, 23 Mar 2010 12:15:25 -0400 Received: from [199.232.76.173] (port=47913 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nu6lI-0004Uy-6A for qemu-devel@nongnu.org; Tue, 23 Mar 2010 12:15:24 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nu6Ua-00048o-Cw for qemu-devel@nongnu.org; Tue, 23 Mar 2010 11:58:10 -0400 Received: from mx20.gnu.org ([199.232.41.8]:32378) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Nu6UI-0003vx-Qb for qemu-devel@nongnu.org; Tue, 23 Mar 2010 11:57:55 -0400 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nu6Tr-0005cv-65 for qemu-devel@nongnu.org; Tue, 23 Mar 2010 11:57:23 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt Date: Tue, 23 Mar 2010 15:57:19 +0000 References: <4BA7C40C.2040505@codemonkey.ws> <20100323145105.GV16253@redhat.com> <4BA8D8A9.7090308@codemonkey.ws> In-Reply-To: <4BA8D8A9.7090308@codemonkey.ws> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003231557.19474.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: "libvir-list@redhat.com" > > 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? Paul