Re: [Qemu-devel] BlockDriverState stack and BlockListeners

[Kevin Wolf <kwolf@redhat.com>]

Am 21.02.2012 12:36, schrieb Paolo Bonzini:
> And here:
> 
>   .== BlockSource ==.
>   | MirrorListener  |                   .== BlockSource ==.
>   | QCOW2View ------+--> QCOW2Format -> | FileProtocol    |
>   '================='    |              '================='
>                          |                                          .== BlockSource ===.
>                          |   .== BlockSource ==.                    | BlkDebugListener |
>                          '-> | QCOW2View ------+--> QCOW2Format --> | FileProtocol     |
>                              '================='                    '=================='
> 
> Does it seem sane?

Yes, this (and the whole explanation that I didn't quote) looks good to
me. For now, at least, until I find the first example where it doesn't
work. Or maybe I can just trust Markus to bring something up.

>> The question is: Can we assume that any listeners that are on top of the
>> first format or protocol (i.e. those that would fit your model) should
>> move to the new top-level view? Or would it sometimes make sense to keep
>> it at the old one?
> 
> I think it depends, but both possibilities should be doable in this model.

Meh. :-)

Maybe we need to introduce something outside of the whole stack, an
entity that is referred to by the device (as in IDE, virtio-blk, ...)
and that refers to a stack of top-level listeners (which would be moved
to the new top-level BlockSource on live snapshot) and to the first
BlockSource (which can have more listeners, and those would stick with
the same BlockSource even if moves down the chain).

Oh, and just to open another can of worms: We should probably design in
the notion of media (which can be ejected etc.) and drives (which always
stay there). We don't have a clean separation today.

Kevin