From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHqnG-0003ya-3T for qemu-devel@nongnu.org; Fri, 06 Sep 2013 03:49:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHqnA-0006Rj-2D for qemu-devel@nongnu.org; Fri, 06 Sep 2013 03:49:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHqn9-0006Ra-QH for qemu-devel@nongnu.org; Fri, 06 Sep 2013 03:49:19 -0400 Date: Fri, 6 Sep 2013 15:49:14 +0800 From: Fam Zheng Message-ID: <20130906074914.GC4814@T430s.nay.redhat.com> References: <20130903162449.GF5285@irqsave.net> <20130904082958.GB8031@stefanha-thinkpad.redhat.com> <20130904181535.GA5073@irqsave.net> <20130905100132.GD12293@stefanha-thinkpad.redhat.com> <20130905101845.GA12304@T430s.nay.redhat.com> <20130905172953.GE5095@irqsave.net> <20130906074202.GD2588@dhcp-200-207.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20130906074202.GD2588@dhcp-200-207.str.redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Block Filters Reply-To: famz@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , jcody@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, Stefan Hajnoczi , pbonzini@redhat.com, mreitz@redhat.com On Fri, 09/06 09:42, Kevin Wolf wrote: > Am 05.09.2013 um 19:29 hat Beno=EEt Canet geschrieben: > > Le Thursday 05 Sep 2013 =E0 18:18:45 (+0800), Fam Zheng a =E9crit : > > > On Thu, 09/05 12:01, Stefan Hajnoczi wrote: > > > > On Wed, Sep 04, 2013 at 08:15:36PM +0200, Beno=EEt Canet wrote: > > > > > > Propagate operations like snapshot down the tree. block.c is= designed > > > > > > for bs->file/bs->backing_hd kind of BlockDrivers, perhaps it = needs to > > > > > > become a bit more generic to support other types of BlockDriv= ers > > > > > > properly. > > > > >=20 > > > > > Shouldn't bs->backing_hd become bs->children[0] and bs->file st= ay the same ? > > > >=20 > > > > bs->backing_hd and bs->file exist so that block.c can implement g= eneric > > > > functionality shared by a lot of block drivers. They are for cod= e > > > > reuse. > > > >=20 > > > > 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. > > > >=20 > > > > 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[]. > > > >=20 > > > > 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. > > > >=20 > > > > ->backing_hd and ->file are mostly image format concepts. Filter= s and > > > > protocols could do without them. > > > >=20 > > > > After saying all that, I don't have a design that makes everythin= g > > > > better :P. > > > >=20 > > >=20 > > > Maybe we could start from a generic scheme and add specific operati= ons upon: > > >=20 > > > I propose we let bs->children[] keep all the node connections, incl= uding > > > backing_hd and file, then leave the BlockDriver, BlockFilter or Blo= ckProtocol > > > to implement ->get_backing_hd(), ->get_file_hd(), or even ->get_fil= es(), or > > > mark an operation as NULL. These operations give semantics to its = children (of > > > course they need some semantics to actually be useful), but it's or= thogonal to > > > management of elements in the object tree. > >=20 > > So would bs->children[] be manipulated directly by each BlockDriver, = BlockFilter > > BlockProtocol implying the their code have an exact knowledge of the = index of > > each bs in bs->children[] ? >=20 > I think the driver implementation is the only one who know how to do it. >=20 > Is creating external snapshots still the only use case for bs->children= [] > in the generic block layer? Because if so, we could indeed rather move > the snapshotting operation into the BlockDrivers. >=20 > Oh, and why are you talking about "BlockDriver, BlockFilter, > BlockProtocol"? What's the difference between them and why isn't the on= e > BlockDriver struct that we have today enough any more? I used the terms with their functional type in mind, didn't mean it's a a= ctual struct in code, they are just block drivers that implement these function= s. Fam