From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60497) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2f3s-0006Ob-BT for qemu-devel@nongnu.org; Wed, 29 Feb 2012 03:39:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S2f3j-0004K5-Pp for qemu-devel@nongnu.org; Wed, 29 Feb 2012 03:38:59 -0500 Received: from mail-bk0-f45.google.com ([209.85.214.45]:51087) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2f3j-0004J7-JA for qemu-devel@nongnu.org; Wed, 29 Feb 2012 03:38:51 -0500 Received: by bkcjg9 with SMTP id jg9so2913438bkc.4 for ; Wed, 29 Feb 2012 00:38:48 -0800 (PST) Message-ID: <4F4DE40C.9020001@zerto.com> Date: Wed, 29 Feb 2012 10:38:36 +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> In-Reply-To: <4F435DD2.8080600@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?= , dlaor@redhat.com, qemu-devel@nongnu.org, Markus Armbruster , Zhi Yong Wu , Federico Simoncelli , Stefan Hajnoczi , Yair Kuszpet , Paolo Bonzini Hi Kevin and all, I think the BlockFilter direction goes very well with our plans for a replication module. I guess it would take some discussions and time to form a solid layer for the BlockFilters, and I'd like to move ahead in parallel with the replication module. What do you say about the following plan: I'll continue with the module development in the spirit of my original RFC, and use a tentative filter-like API to block.c that I'll add. Then I can submit the patches, get comments for the internal parts of the filter, and later on when some form of generic BlockFilter API is there - I can change my filter to use it. This way we can have some anchor in Qemu to work with and develop the rest of the management parts. Does it sound reasonable? Thanks, Ori