Re: [Qemu-devel] BlockDriverState stack and BlockListeners

[Markus Armbruster]

Kevin Wolf <address@hidden> writes:

> 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).

The top-level BDS is already special.  I think it makes sense to factor
out the specialness into a "block backend" type, and let it point to a
non-special block driver instance (root of a tree of block driver
instances, in general).

> 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.

The "closed BDS means no media" thing works, but it's odd.