Re: [Qemu-devel] Block Filters

[Fam Zheng]

On Fri, 09/06 09:42, Kevin Wolf wrote:
> Am 05.09.2013 um 19:29 hat Benoît Canet geschrieben:
> > Le Thursday 05 Sep 2013 à 18:18:45 (+0800), Fam Zheng a écrit :
> > > On Thu, 09/05 12:01, Stefan Hajnoczi wrote:
> > > > On Wed, Sep 04, 2013 at 08:15:36PM +0200, Benoît 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 BlockDrivers
> > > > > > properly.
> > > > > 
> > > > > Shouldn't bs->backing_hd become bs->children[0] and bs->file stay the 
> > > > > same ?
> > > > 
> > > > 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[].
> > > > 
> > > > 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.
> > > > 
> > > 
> > > Maybe we could start from a generic scheme and add specific operations 
> > > upon:
> > > 
> > > I propose we let bs->children[] keep all the node connections, including
> > > backing_hd and file, then leave the BlockDriver, BlockFilter or 
> > > BlockProtocol
> > > to implement ->get_backing_hd(), ->get_file_hd(), or even ->get_files(), 
> > > 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 
> > > orthogonal to
> > > management of elements in the object tree.
> > 
> > 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[] ?
> 
> I think the driver implementation is the only one who know how to do it.
> 
> 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.
> 
> Oh, and why are you talking about "BlockDriver, BlockFilter,
> BlockProtocol"? What's the difference between them and why isn't the one
> 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 actual
struct in code, they are just block drivers that implement these functions.

Fam