Re: [Qemu-devel] [PATCH for 2.1 0/2] Fix commit of oversized layer

[Fam Zheng]

On Fri, 06/27 11:44, Kevin Wolf wrote:
> In general, it feels like it would be the right thing to do, especially
> considering the goal of operation categories in the final state, but on
> the other hand it means that RESIZE would have to be excluded from
> bs->backing_blocker, too, allowing standalone resize commands on backing
> files. Not sure that this would be a good idea...

Is it really dangerous if we relax the backing_blocker on resize? In general, I
expect the only critical category of operation is chain manipulation,
particularly bdrv_swap.

And speaking of bdrv_swap, in longer term, if we have the BlockBackend that can
serve as a level of abstraction between BlockDriverState (the backend
implementation) and its users (the backend consumers, like device), we can
probably drop bdrv_swap() by updating the BB->BDS link.

To illustrate:

    [top] <----------- device emulation
      |        |------ NBD server
      |        `------ commit block job
    [mid]
      |
    [bot]

When we commit top to mid, bdrv_swap will move the data into original top's
position, so the old users of top now automatically start to use mid (of
course, it is assigned some properties of top, like device name).

    [mid] <----------- device emulation
      |        |------ NBD server
      |        `------ commit block job (done)
      |
    [bot]

Where the original [mid]'s memory is freed (bdrv_unref, precisely).

With the imaginary BlockBackend, we start over again:

    [top] <----------- <backend0> <------- device emulation
      |                    |          `--- NBD server
      |                    |
      |                commit block job
    [mid]
      |
    [bot]

Now the block job, device and NBD server all uses BlockBackend <backend0>, who
represents an endpoint for the blockdev operations. Normally they don't care
who is behind backend0, except that block job will look at the backing BDSes,
because in order to commit through the chain, it has to know the topology
behind it.

When the job is done, block job can safely update the backend's link to point
to [bot], while all the other backend user's pointers remain valid because we
don't move backend0 around. Everyone is happy.

    [top]      /------ <backend0> <------- device emulation
      |        |           |          `--- NBD server
      |        |           |
      |        |       commit block job (done)
    [mid]      |
      |        |
    [bot] <----/

Is this a good direction?

Fam