Re: [Qemu-devel] BlockDriverState stack and BlockListeners

From: Kevin Wolf <kwolf@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "תומר בן אור" <tomer@zertodata.com>, "עודד קדם" <oded@zerto.com>,
	"Jeff Cody" <jcody@redhat.com>,
	dlaor@redhat.com, qemu-devel@nongnu.org,
	"Zhi Yong Wu" <zwu.kernel@gmail.com>,
	"Federico Simoncelli" <fsimonce@redhat.com>,
	"Ori Mamluk" <omamluk@zerto.com>,
	"Stefan Hajnoczi" <stefanha@gmail.com>,
	"Yair Kuszpet" <yairk@zerto.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] BlockDriverState stack and BlockListeners
Date: Tue, 21 Feb 2012 17:04:39 +0100	[thread overview]
Message-ID: <4F43C097.9050308@redhat.com> (raw)
In-Reply-To: <m339a46uz6.fsf@blackfin.pond.sub.org>

Am 21.02.2012 16:56, schrieb Markus Armbruster:
> Kevin Wolf <kwolf@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).

I think this is what I meant.

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

I'm more talking about data that belongs to the media, like geometry.
This came up recently with Hervé's floppy patches.

Kevin