[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] BlockDriverState stack and BlockListeners
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] BlockDriverState stack and BlockListeners |
Date: |
Tue, 21 Feb 2012 16:56:29 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) |
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.
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, (continued)
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Paolo Bonzini, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Kevin Wolf, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Paolo Bonzini, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Kevin Wolf, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Paolo Bonzini, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Stefan Hajnoczi, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Paolo Bonzini, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Markus Armbruster, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Kevin Wolf, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Paolo Bonzini, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners,
Markus Armbruster <=
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Kevin Wolf, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Markus Armbruster, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Kevin Wolf, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Stefan Hajnoczi, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Ori Mamluk, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Ori Mamluk, 2012/02/29
- Re: [Qemu-devel] [RFC PATCH] replication agent module, Stefan Hajnoczi, 2012/02/08
- [Qemu-devel] [RFC] Replication agent requirements (was [RFC PATCH] replication agent module), Ori Mamluk, 2012/02/08
- Re: [Qemu-devel] [RFC] Replication agent requirements (was [RFC PATCH] replication agent module), Anthony Liguori, 2012/02/08
- Re: [Qemu-devel] [RFC PATCH] replication agent module, Stefan Hajnoczi, 2012/02/08