Re: [Qemu-devel] Block Filters

[Kevin Wolf <kwolf@redhat.com>]

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?

Kevin