From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33837) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzpRE-00087N-0n for qemu-devel@nongnu.org; Tue, 21 Feb 2012 08:07:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzpR7-0002Cw-Mi for qemu-devel@nongnu.org; Tue, 21 Feb 2012 08:07:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:20892) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzpR7-0002Ce-A1 for qemu-devel@nongnu.org; Tue, 21 Feb 2012 08:07:17 -0500 Message-ID: <4F4397D1.2020807@redhat.com> Date: Tue, 21 Feb 2012 14:10:41 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <73865e0ce364c40e0eb65ec6b22b819d@mail.gmail.com> <4F31153E.9010205@codemonkey.ws> <4F311839.9030709@redhat.com> <4F311BBA.8000708@codemonkey.ws> <4F312FD3.5020206@zerto.com> <4F3137DB.1040503@redhat.com> <4F3139CE.4040103@zerto.com> <4F314798.8010009@redhat.com> <4F3211D0.3070502@zerto.com> <4F323875.1000000@redhat.com> <4F3244C2.1040604@zerto.com> <4F32489A.80307@redhat.com> <4F32788C.60904@zerto.com> <4F40FBD6.2000500@zerto.com> <4F425987.20103@redhat.com> <4F435DD2.8080600@redhat.com> <4F4360C7.5080806@redhat.com> <4F4368BF.4040707@redhat.com> <4F436D76.6090206@redhat.com> <4F43773B.6060109@redhat.com> <4F4381CE.70604@redhat.com> In-Reply-To: <4F4381CE.70604@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] BlockDriverState stack and BlockListeners List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: =?UTF-8?B?16rXldee16gg15HXnyDXkNeV16g=?= , Stefan Hajnoczi , Jeff Cody , dlaor@redhat.com, qemu-devel@nongnu.org, Markus Armbruster , Zhi Yong Wu , Federico Simoncelli , Ori Mamluk , =?UTF-8?B?16LXldeT15Mg16fXk9ed?= , Yair Kuszpet 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