From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52256 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGuUP-0006Ky-Ee for qemu-devel@nongnu.org; Tue, 25 May 2010 09:48:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGuEa-0008QC-Bg for qemu-devel@nongnu.org; Tue, 25 May 2010 09:31:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50185) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGuEa-0008Px-4n for qemu-devel@nongnu.org; Tue, 25 May 2010 09:31:52 -0400 Message-ID: <4BFBD13C.60605@redhat.com> Date: Tue, 25 May 2010 16:31:40 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm References: <20100519192222.GD61706@ncolin.muc.de> <4BF5A9D2.5080609@codemonkey.ws> <4BF91937.2070801@redhat.com> <4BFBAE46.5050801@redhat.com> <4BFBB3C1.9020905@redhat.com> <4BFBCFAC.9070807@codemonkey.ws> In-Reply-To: <4BFBCFAC.9070807@codemonkey.ws> 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: Anthony Liguori Cc: Kevin Wolf , kvm@vger.kernel.org, qemu-devel@nongnu.org, Blue Swirl , ceph-devel@vger.kernel.org, Christian Brunner On 05/25/2010 04:25 PM, Anthony Liguori wrote: >> Currently if someone wants to add a new block format, they have to >> upstream it and wait for a new qemu to be released. With a plugin >> API, they can add a new block format to an existing, supported qemu. > > > Whether we have a plugin or protocol based mechanism to implement > block formats really ends up being just an implementation detail. True. > In order to implement either, we need to take a subset of block > functionality that we feel we can support long term and expose that. > Right now, that's basically just querying characteristics (like size > and geometry) and asynchronous reads and writes. Unfortunately, you're right. > A protocol based mechanism has the advantage of being more robust in > the face of poorly written block backends so if it's possible to make > it perform as well as a plugin, it's a preferable approach. May be hard due to difficulty of exposing guest memory. > > Plugins that just expose chunks of QEMU internal state directly (like > BlockDriver) are a really bad idea IMHO. Also, we don't want to expose all of the qemu API. We should default the visibility attribute to "hidden" and expose only select functions, perhaps under their own interface. And no inlines. -- error compiling committee.c: too many arguments to function