Re: [Qemu-devel] Block Filters

[Fam Zheng <famz@redhat.com>]

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.

Fam