Re: [Qemu-devel] Block Filters

[Stefan Hajnoczi <stefanha@redhat.com>]

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[].

The block driver can put constraints on ->children[], e.g. how many
children are allowed, read/write access, etc.  .bdrv_open() can look at
->children[] and set things up.

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.

Stefan