On Thu, Sep 05, 2013 at 06:18:45PM +0800, Fam Zheng wrote: > 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.
Yes, plus a mapping to the command-line/QOM (e.g. backing.cache=writeback instead of children[1].cache=writeback). Stefan