qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Block Filters


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] Block Filters
Date: Thu, 5 Sep 2013 16:59:25 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]