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
