From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37194) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzmqS-0003BJ-R6 for qemu-devel@nongnu.org; Tue, 21 Feb 2012 05:21:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzmqI-0001uw-SV for qemu-devel@nongnu.org; Tue, 21 Feb 2012 05:21:16 -0500 Received: from mail-bk0-f45.google.com ([209.85.214.45]:55559) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzmqI-0001uj-HA for qemu-devel@nongnu.org; Tue, 21 Feb 2012 05:21:06 -0500 Received: by bkue19 with SMTP id e19so5985323bku.4 for ; Tue, 21 Feb 2012 02:21:04 -0800 (PST) Message-ID: <4F437001.4000707@zerto.com> Date: Tue, 21 Feb 2012 12:20:49 +0200 From: Ori Mamluk 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> In-Reply-To: <4F4368BF.4040707@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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: Kevin Wolf Cc: =?UTF-8?B?16rXldee16gg15HXnyDXkNeV16g=?= , =?UTF-8?B?16LXldeT15Mg16fXk9ed?= , Jeff Cody , dlaor@redhat.com, qemu-devel@nongnu.org, Markus Armbruster , Zhi Yong Wu , Federico Simoncelli , Stefan Hajnoczi , Yair Kuszpet , Paolo Bonzini On 21/02/2012 11:49, Kevin Wolf wrote: > Am 21.02.2012 10:15, schrieb Paolo Bonzini: >>> So maybe we just need to extend the current BlockDriverState stack to >>> distinguish "normal" and "always on top" BlockDrivers, where the latter >>> would roughly correspond to BlockListeners? >> I would prefer having separate objects. Even if you do not count fields >> related to throttling or copy-on-read or other tasks in the list above, >> there are many fields in BDS that do not really apply to BlockListeners. >> Backing files, device ops, encryption, even size. Having extra methods >> is not a big problem, but unwanted data items smell... > Most other block drivers use only little of them. We can try to clean up > some of them (and making the separation described above would probably > help with it), but BlockListeners aren't really different here from > existing drivers. My impression as an outside observer was similar - it appears as though the block driver object contains stuff that belongs to the specific driver (e.g. bitmap). An additional capability that I need in the replication filter is for the driver to initiate a new IO. It means that if we have a stack of drivers guest->bdrv1->bdrv2->bdrv3->image, then bdrv2 should be able to invoke a read - which will be processed only by deeper parts of the stack - i.e. bdrv3. Makes sense? For question of upper/lower drivers, I tend to think that there are two kinds - those who need the original guest IO transactions and those who transform them. Maybe two separate drivers stack (upper and lower) are enough to implement this difference. > Kevin