From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42029) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzsRo-0007aN-BZ for qemu-devel@nongnu.org; Tue, 21 Feb 2012 11:20:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzsRd-00028n-4P for qemu-devel@nongnu.org; Tue, 21 Feb 2012 11:20:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzsRc-00028h-RU for qemu-devel@nongnu.org; Tue, 21 Feb 2012 11:20:01 -0500 From: Markus Armbruster References: <73865e0ce364c40e0eb65ec6b22b819d@mail.gmail.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> <4F43C097.9050308@redhat.com> Date: Tue, 21 Feb 2012 17:19:56 +0100 In-Reply-To: <4F43C097.9050308@redhat.com> (Kevin Wolf's message of "Tue, 21 Feb 2012 17:04:39 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 16:56, schrieb Markus Armbruster: >> Kevin Wolf writes: [...] >>> 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). >>=20 >> 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. Then we're in violent agreement :) >>> 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. >>=20 >> 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=C3=A9's floppy patches. Is geometry relevant to anything but floppies and really small disks being accessed via really old interfaces?