From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53375) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHdLb-0007ck-3j for qemu-devel@nongnu.org; Thu, 05 Sep 2013 13:28:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHdLV-0003rp-00 for qemu-devel@nongnu.org; Thu, 05 Sep 2013 13:27:59 -0400 Received: from nodalink.pck.nerim.net ([62.212.105.220]:60559 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHdLU-0003rk-Ls for qemu-devel@nongnu.org; Thu, 05 Sep 2013 13:27:52 -0400 Date: Thu, 5 Sep 2013 19:29:53 +0200 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20130905172953.GE5095@irqsave.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20130905101845.GA12304@T430s.nay.redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Block Filters List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , kwolf@redhat.com, jcody@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, Stefan Hajnoczi , pbonzini@redhat.com, mreitz@redhat.com 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 des= igned > > > > for bs->file/bs->backing_hd kind of BlockDrivers, perhaps it need= s 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 t= he same ? > >=20 > > bs->backing_hd and bs->file exist so that block.c can implement gener= ic > > functionality shared by a lot of block drivers. They are for code > > 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 tre= es, > > 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. Filters an= d > > protocols could do without them. > >=20 > > After saying all that, I don't have a design that makes everything > > better :P. > >=20 >=20 > Maybe we could start from a generic scheme and add specific operations = upon: >=20 > I propose we let bs->children[] keep all the node connections, includin= g > backing_hd and file, then leave the BlockDriver, BlockFilter or BlockPr= otocol > to implement ->get_backing_hd(), ->get_file_hd(), or even ->get_files()= , or > mark an operation as NULL. These operations give semantics to its chil= dren (of > course they need some semantics to actually be useful), but it's orthog= onal to > management of elements in the object tree. So would bs->children[] be manipulated directly by each BlockDriver, Bloc= kFilter BlockProtocol implying the their code have an exact knowledge of the inde= x of each bs in bs->children[] ? Best regards Beno=EEt