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 12:01:32 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

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