From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:34120)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1a1ppv-0005l3-62
	for qemu-devel@nongnu.org; Thu, 26 Nov 2015 01:15:19 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1a1ppu-0006fi-C0
	for qemu-devel@nongnu.org; Thu, 26 Nov 2015 01:15:19 -0500
Date: Thu, 26 Nov 2015 14:15:08 +0800
From: Fam Zheng <famz@redhat.com>
Message-ID: <20151126061508.GH14630@ad.usersys.redhat.com>
References: <1448425160-26092-1-git-send-email-famz@redhat.com>
	<56555BEB.8080105@virtuozzo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56555BEB.8080105@virtuozzo.com>
Subject: Re: [Qemu-devel] [PATCH v3 0/4] Bitmap clean-up patches for 2.6
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-block@nongnu.org, Jeff Cody <jcody@redhat.com>, qemu-devel@nongnu.org, mreitz@redhat.com, pbonzini@redhat.com, jsnow@redhat.com

On Wed, 11/25 09:57, Vladimir Sementsov-Ogievskiy wrote:
> Hmm, stop. Very bad thing (sorry, that I didn't realize it before):
> 
> This breaks my dirty bitmap migration series with its meta bitmaps.
> Meta bitmap is an additional HBitmap in BdrvDirtyBitmap, which
> tracks dirtiness of this BdrvDirtyBitmap. And it (meta bitmap) have
> its own granularity of course. Or we will have to maintain
> additional meta_gran_shift and lots of duplicated code..
> 
> If we speak about splitting granularity out of HBitmap, then the
> most true way should be
> 
> struct HBitmapGranuled {
>   struct HBitmap *hb;
>   uint32_t gran_shift;
> }
> 
> with all supporting functions and iterators.

Then it's not worth making this change, let's drop patch 3 & 4 for now.

Fam