From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53514) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHWNk-0006vL-5t for qemu-devel@nongnu.org; Thu, 05 Sep 2013 06:01:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHWNe-00054N-5N for qemu-devel@nongnu.org; Thu, 05 Sep 2013 06:01:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHWNd-00054J-Sx for qemu-devel@nongnu.org; Thu, 05 Sep 2013 06:01:38 -0400 Date: Thu, 5 Sep 2013 12:01:32 +0200 From: Stefan Hajnoczi Message-ID: <20130905100132.GD12293@stefanha-thinkpad.redhat.com> References: <20130903162449.GF5285@irqsave.net> <20130904082958.GB8031@stefanha-thinkpad.redhat.com> <20130904181535.GA5073@irqsave.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20130904181535.GA5073@irqsave.net> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Block Filters List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?iso-8859-1?Q?Beno=EEt?= Canet Cc: kwolf@redhat.com, famz@redhat.com, jcody@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com, mreitz@redhat.com On Wed, Sep 04, 2013 at 08:15:36PM +0200, Beno=EEt Canet wrote: > > Propagate operations like snapshot down the tree. block.c is designe= d > > for bs->file/bs->backing_hd kind of BlockDrivers, perhaps it needs to > > become a bit more generic to support other types of BlockDrivers > > properly. >=20 > Shouldn't bs->backing_hd become bs->children[0] and bs->file stay the s= ame ? bs->backing_hd and bs->file exist so that block.c can implement generic functionality shared by a lot of block drivers. They are for code reuse. Many places in the block layer have come to assume that there is only one ->file, for example. That's not true for quorum or even vmdk. If we forget about code reuse for a second, and just think of BDS trees, then both ->backing_hd and ->file should be in ->children[]. The block driver can put constraints on ->children[], e.g. how many children are allowed, read/write access, etc. .bdrv_open() can look at ->children[] and set things up. I think the problem we have is that too much of QEMU uses ->file and ->backing_hd. It's kind of baked in now to the point where more flexible block drivers like quorum are hard to represent. ->backing_hd and ->file are mostly image format concepts. Filters and protocols could do without them. After saying all that, I don't have a design that makes everything better :P. Stefan