Re: [PATCH v2 01/10] string: introduce memweight

[Jan Kara]

On Mon 04-06-12 20:46:14, Akinobu Mita wrote:
> 2012/6/4 Jan Kara <jack@xxxxxxx>:
> > On Sat 02-06-12 22:40:07, Akinobu Mita wrote:
> >> memweight() is the function that counts the total number of bits set
> >> in memory area.  Unlike bitmap_weight(), memweight() takes pointer
> >> and size in bytes to specify a memory area which does not need to be
> >> aligned to long-word boundary.
> >>
> >> Signed-off-by: Akinobu Mita <akinobu.mita@xxxxxxxxx>
> >> Cc: Anders Larsen <al@xxxxxxxxxxx>
> >> Cc: Alasdair Kergon <agk@xxxxxxxxxx>
> >> Cc: dm-devel@xxxxxxxxxx
> >> Cc: linux-fsdevel@xxxxxxxxxxxxxxx
> >> Cc: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
> >> Cc: linux-media@xxxxxxxxxxxxxxx
> >> Cc: Mark Fasheh <mfasheh@xxxxxxxx>
> >> Cc: Joel Becker <jlbec@xxxxxxxxxxxx>
> >> Cc: ocfs2-devel@xxxxxxxxxxxxxx
> >> Cc: Jan Kara <jack@xxxxxxx>
> >> Cc: linux-ext4@xxxxxxxxxxxxxxx
> >> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> >> Cc: Andreas Dilger <adilger.kernel@xxxxxxxxx>
> >> Cc: "Theodore Ts'o" <tytso@xxxxxxx>
> >> Cc: Matthew Wilcox <matthew@xxxxxx>
> >> ---
> >>
> >> v2: simplify memweight(), adviced by Jan Kara
> >>
> >>  include/linux/string.h |    3 +++
> >>  lib/string.c           |   32 ++++++++++++++++++++++++++++++++
> >>  2 files changed, 35 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/include/linux/string.h b/include/linux/string.h
> >> index e033564..ffe0442 100644
> >> --- a/include/linux/string.h
> >> +++ b/include/linux/string.h
> >> @@ -145,4 +145,7 @@ static inline bool strstarts(const char *str, const char *prefix)
> >>       return strncmp(str, prefix, strlen(prefix)) == 0;
> >>  }
> >>  #endif
> >> +
> >> +extern size_t memweight(const void *ptr, size_t bytes);
> >> +
> >>  #endif /* _LINUX_STRING_H_ */
> >> diff --git a/lib/string.c b/lib/string.c
> >> index e5878de..bf4d5a8 100644
> >> --- a/lib/string.c
> >> +++ b/lib/string.c
> >> @@ -26,6 +26,7 @@
> >>  #include <linux/export.h>
> >>  #include <linux/bug.h>
> >>  #include <linux/errno.h>
> >> +#include <linux/bitmap.h>
> >>
> >>  #ifndef __HAVE_ARCH_STRNICMP
> >>  /**
> >> @@ -824,3 +825,34 @@ void *memchr_inv(const void *start, int c, size_t bytes)
> >>       return check_bytes8(start, value, bytes % 8);
> >>  }
> >>  EXPORT_SYMBOL(memchr_inv);
> >> +
> >> +/**
> >> + * memweight - count the total number of bits set in memory area
> >> + * @ptr: pointer to the start of the area
> >> + * @bytes: the size of the area
> >> + */
> >> +size_t memweight(const void *ptr, size_t bytes)
> >> +{
> >> +     size_t w = 0;
> >> +     size_t longs;
> >> +     const unsigned char *bitmap = ptr;
> >> +
> >> +     for (; bytes > 0 && ((unsigned long)bitmap) % sizeof(long);
> >> +                     bytes--, bitmap++)
> >> +             w += hweight8(*bitmap);
> >> +
> >> +     longs = bytes / sizeof(long);
> >> +     if (longs) {
> >> +             BUG_ON(longs >= INT_MAX / BITS_PER_LONG);
> >> +             w += bitmap_weight((unsigned long *)bitmap,
> >> +                             longs * BITS_PER_LONG);
> >> +             bytes -= longs * sizeof(long);
> >> +             bitmap += longs * sizeof(long);
> >> +     }
> >> +
> >> +     for (; bytes > 0; bytes--, bitmap++)
> >> +             w += hweight8(*bitmap);
> >  Looking at bitmap_weight() it seems this last loop is not needed. Just
> > pass to bitmap_weight() bytes*BITS_PER_BYTE. Also generally this function
> > doesn't seem necessary at all at least for ext2 & ext3 (sorry for not
> > noticing this earlier...).
> 
> This last loop is necessary for big-endian architecture.
> if bytes % sizeof(long) != 0, bitmap_weight() counts one-bits in wrong
> byte-field
> of the last long word.
  Ah, right. OK. Add this to the comment before the loop please. You save
yourself some explanations :)

								Honza
-- 
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/