From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54314) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rzs52-0004gi-1v for qemu-devel@nongnu.org; Tue, 21 Feb 2012 10:56:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rzs4v-0005Eh-Sk for qemu-devel@nongnu.org; Tue, 21 Feb 2012 10:56:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52031) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rzs4v-0005ES-Jc for qemu-devel@nongnu.org; Tue, 21 Feb 2012 10:56:33 -0500 From: Markus Armbruster References: <73865e0ce364c40e0eb65ec6b22b819d@mail.gmail.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> <4F4397D1.2020807@redhat.com> Date: Tue, 21 Feb 2012 16:56:29 +0100 In-Reply-To: <4F4397D1.2020807@redhat.com> (Kevin Wolf's message of "Tue, 21 Feb 2012 14:10:41 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] BlockDriverState stack and BlockListeners List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: =?utf-8?B?16rXldee?= =?utf-8?B?16gg15HXnyDXkNeV16g=?= , =?utf-8?B?16I=?= =?utf-8?B?15XXk9eTINen15PXnQ==?= , Jeff Cody , dlaor@redhat.com, qemu-devel@nongnu.org, Zhi Yong Wu , Federico Simoncelli , Ori Mamluk , Stefan Hajnoczi , Yair Kuszpet , Paolo Bonzini Kevin Wolf 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.