From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46137) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHb22-0005oD-GK for qemu-devel@nongnu.org; Thu, 05 Sep 2013 10:59:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHb1w-0007Pz-Fd for qemu-devel@nongnu.org; Thu, 05 Sep 2013 10:59:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25222) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHb1w-0007Pa-88 for qemu-devel@nongnu.org; Thu, 05 Sep 2013 10:59:32 -0400 Date: Thu, 5 Sep 2013 16:59:25 +0200 From: Stefan Hajnoczi Message-ID: <20130905145925.GA24626@stefanha-thinkpad.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> 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, pbonzini@redhat.com, mreitz@redhat.com On Thu, Sep 05, 2013 at 06:18:45PM +0800, Fam Zheng wrote: > 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. Yes, plus a mapping to the command-line/QOM (e.g. backing.cache=3Dwriteback instead of children[1].cache=3Dwriteback). Stefan