On Fri, 09/06 09:42, Kevin Wolf wrote: > 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?
I used the terms with their functional type in mind, didn't mean it's a actual struct in code, they are just block drivers that implement these functions. Fam