Kevin Wolf <kw...@redhat.com> 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.
