From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57287) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VszNG-0003QD-5W for qemu-devel@nongnu.org; Tue, 17 Dec 2013 13:28:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VszNA-0002WZ-G1 for qemu-devel@nongnu.org; Tue, 17 Dec 2013 13:28:06 -0500 Received: from [2a03:4000:1::4e2f:c7ac:d] (port=39893 helo=v220110690675601.yourvserver.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VszNA-0002WT-9C for qemu-devel@nongnu.org; Tue, 17 Dec 2013 13:28:00 -0500 Message-ID: <52B097AC.4070200@weilnetz.de> Date: Tue, 17 Dec 2013 19:27:56 +0100 From: Stefan Weil MIME-Version: 1.0 References: <1387293974-24718-1-git-send-email-quintela@redhat.com> <1387293974-24718-2-git-send-email-quintela@redhat.com> <52B09268.6000400@redhat.com> In-Reply-To: <52B09268.6000400@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 01/38] bitmap: use long as index List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , Juan Quintela , qemu-devel@nongnu.org Am 17.12.2013 19:05, schrieb Eric Blake: > On 12/17/2013 08:25 AM, Juan Quintela wrote: >> Move index and size fields from int to long. We need that for >> migration. long is 64 bits on sane architectures, and 32bits should >> be enough on all the 32bits architectures. Does this also work for "insane" architectures like Windows (64 bit) where long is only 32 bit? Wouldn't uintptr_t or intptr_t be better (also for x32)? >> >> >> Signed-off-by: Juan Quintela >> --- >> include/qemu/bitmap.h | 77 ++++++++++++++++++++++++++------------------------- >> include/qemu/bitops.h | 14 +++++----- >> util/bitmap.c | 60 +++++++++++++++++++-------------------- >> 3 files changed, 76 insertions(+), 75 deletions(-) >> >> diff --git a/include/qemu/bitmap.h b/include/qemu/bitmap.h >> index 308bbb7..afdd257 100644 >> --- a/include/qemu/bitmap.h >> +++ b/include/qemu/bitmap.h >> @@ -31,7 +31,7 @@ >> * bitmap_andnot(dst, src1, src2, nbits) *dst = *src1 & ~(*src2) >> * bitmap_complement(dst, src, nbits) *dst = ~(*src) >> * bitmap_equal(src1, src2, nbits) Are *src1 and *src2 equal? >> - * bitmap_intersects(src1, src2, nbits) Do *src1 and *src2 overlap? >> + * bitmap_intersects(src1, src2, nbits) Do *src1 and *src2 overlap? > > Spurious whitespace change? > >> * bitmap_empty(src, nbits) Are all bits zero in *src? >> * bitmap_full(src, nbits) Are all bits set in *src? >> * bitmap_set(dst, pos, nbits) Set specified bit area >> @@ -62,71 +62,71 @@ >> ) >> >> #define DECLARE_BITMAP(name,bits) \ >> - unsigned long name[BITS_TO_LONGS(bits)] >> + unsigned long name[BITS_TO_LONGS(bits)] >> >> #define small_nbits(nbits) \ >> - ((nbits) <= BITS_PER_LONG) >> + ((nbits) <= BITS_PER_LONG) > > Whitespace change, but in same hunk as real changes, so ok for > checkpatch.pl reasons. > >> +++ b/include/qemu/bitops.h >> @@ -28,7 +28,7 @@ >> * @nr: the bit to set >> * @addr: the address to start counting from >> */ >> -static inline void set_bit(int nr, unsigned long *addr) >> +static inline void set_bit(long nr, unsigned long *addr) >> { >> unsigned long mask = BIT_MASK(nr); >> unsigned long *p = addr + BIT_WORD(nr); > > Worth cleaning up this whitespace while in the area? > > Content changes seem sane to me: > Reviewed-by: Eric Blake > Cheers, Stefan