From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm Date: Tue, 25 May 2010 08:25:00 -0500 Message-ID: <4BFBCFAC.9070807@codemonkey.ws> References: <20100519192222.GD61706@ncolin.muc.de> <4BF5A9D2.5080609@codemonkey.ws> <4BF91937.2070801@redhat.com> <4BFBAE46.5050801@redhat.com> <4BFBB3C1.9020905@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kevin Wolf , Blue Swirl , ceph-devel@vger.kernel.org, Christian Brunner , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Avi Kivity Return-path: Received: from mail-vw0-f46.google.com ([209.85.212.46]:55831 "EHLO mail-vw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756198Ab0EYNZF (ORCPT ); Tue, 25 May 2010 09:25:05 -0400 In-Reply-To: <4BFBB3C1.9020905@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 05/25/2010 06:25 AM, Avi Kivity wrote: > On 05/25/2010 02:02 PM, Kevin Wolf wrote: >> >>> >>>> So could we not standardize a protocol for this that both sheepdog and >>>> ceph could implement? >>> The protocol already exists, nbd. It doesn't support snapshotting etc. >>> but we could extend it. >>> >>> But IMO what's needed is a plugin API for the block layer. >> What would it buy us, apart from more downstreams and having to maintain >> a stable API and ABI? > > 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. 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. 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. Plugins that just expose chunks of QEMU internal state directly (like BlockDriver) are a really bad idea IMHO. Regards, Anthony Liguori