From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Alexander Potapenko <glider@google.com>
Cc: catalin.marinas@arm.com, will@kernel.org, pcc@google.com,
andreyknvl@gmail.com, aleksander.lobakin@intel.com,
linux@rasmusvillemoes.dk, yury.norov@gmail.com,
alexandru.elisei@arm.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, eugenis@google.com,
syednwaris@gmail.com, william.gray@linaro.org,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v9 1/2] lib/bitmap: add bitmap_{read,write}()
Date: Thu, 26 Oct 2023 15:15:40 +0300 [thread overview]
Message-ID: <ZTpYbCa0Qmry0HGH@smile.fi.intel.com> (raw)
In-Reply-To: <20231025083812.456916-1-glider@google.com>
On Wed, Oct 25, 2023 at 10:38:11AM +0200, Alexander Potapenko wrote:
> From: Syed Nayyar Waris <syednwaris@gmail.com>
>
> The two new functions allow reading/writing values of length up to
> BITS_PER_LONG bits at arbitrary position in the bitmap.
>
> The code was taken from "bitops: Introduce the for_each_set_clump macro"
> by Syed Nayyar Waris with a number of changes and simplifications:
> - instead of using roundup(), which adds an unnecessary dependency
> on <linux/math.h>, we calculate space as BITS_PER_LONG-offset;
> - indentation is reduced by not using else-clauses (suggested by
> checkpatch for bitmap_get_value());
> - bitmap_get_value()/bitmap_set_value() are renamed to bitmap_read()
> and bitmap_write();
> - some redundant computations are omitted.
...
> * bitmap_to_arr64(buf, src, nbits) Copy nbits from buf to u64[] dst
> * bitmap_get_value8(map, start) Get 8bit value from map at start
> * bitmap_set_value8(map, value, start) Set 8bit value to map at start
> + * bitmap_read(map, start, nbits) Read an nbits-sized value from
> + * map at start
> + * bitmap_write(map, value, start, nbits) Write an nbits-sized value to
> + * map at start
I still didn't get the grouping you implied with this...
> * Note, bitmap_zero() and bitmap_fill() operate over the region of
> * unsigned longs, that is, bits behind bitmap till the unsigned long
...
> +/**
> + * bitmap_read - read a value of n-bits from the memory region
> + * @map: address to the bitmap memory region
> + * @start: bit offset of the n-bit value
> + * @nbits: size of value in bits, nonzero, up to BITS_PER_LONG
> + *
> + * Returns: value of nbits located at the @start bit offset within the @map
> + * memory region.
> + *
> + * Note: callers on 32-bit systems must be careful to not attempt reading more
> + * than sizeof(unsigned long).
sizeof() here is misleading, We talk about bits, BITS_PER_LONG (which is 32),
here it's better to be explicit that reading more than 32 bits at a time on
32-bit platform will return 0. Actually what you need is to describe...
> + */
> +static inline unsigned long bitmap_read(const unsigned long *map,
> + unsigned long start,
> + unsigned long nbits)
> +{
> + size_t index = BIT_WORD(start);
> + unsigned long offset = start % BITS_PER_LONG;
> + unsigned long space = BITS_PER_LONG - offset;
> + unsigned long value_low, value_high;
> +
> + if (unlikely(!nbits || nbits > BITS_PER_LONG))
> + return 0;
...this return in the Return section.
> +
> + if (space >= nbits)
> + return (map[index] >> offset) & BITMAP_LAST_WORD_MASK(nbits);
> +
> + value_low = map[index] & BITMAP_FIRST_WORD_MASK(start);
> + value_high = map[index + 1] & BITMAP_LAST_WORD_MASK(start + nbits);
> + return (value_low >> offset) | (value_high << space);
> +}
...
> +/**
> + * bitmap_write - write n-bit value within a memory region
> + * @map: address to the bitmap memory region
> + * @value: value to write, clamped to nbits
> + * @start: bit offset of the n-bit value
> + * @nbits: size of value in bits, nonzero, up to BITS_PER_LONG.
> + *
> + * bitmap_write() behaves as-if implemented as @nbits calls of __assign_bit(),
> + * i.e. bits beyond @nbits are ignored:
> + *
> + * for (bit = 0; bit < nbits; bit++)
> + * __assign_bit(start + bit, bitmap, val & BIT(bit));
> + * Note: callers on 32-bit systems must be careful to not attempt writing more
> + * than sizeof(unsigned long).
Ditto.
> + */
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Alexander Potapenko <glider@google.com>
Cc: catalin.marinas@arm.com, will@kernel.org, pcc@google.com,
andreyknvl@gmail.com, aleksander.lobakin@intel.com,
linux@rasmusvillemoes.dk, yury.norov@gmail.com,
alexandru.elisei@arm.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, eugenis@google.com,
syednwaris@gmail.com, william.gray@linaro.org,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v9 1/2] lib/bitmap: add bitmap_{read,write}()
Date: Thu, 26 Oct 2023 15:15:40 +0300 [thread overview]
Message-ID: <ZTpYbCa0Qmry0HGH@smile.fi.intel.com> (raw)
In-Reply-To: <20231025083812.456916-1-glider@google.com>
On Wed, Oct 25, 2023 at 10:38:11AM +0200, Alexander Potapenko wrote:
> From: Syed Nayyar Waris <syednwaris@gmail.com>
>
> The two new functions allow reading/writing values of length up to
> BITS_PER_LONG bits at arbitrary position in the bitmap.
>
> The code was taken from "bitops: Introduce the for_each_set_clump macro"
> by Syed Nayyar Waris with a number of changes and simplifications:
> - instead of using roundup(), which adds an unnecessary dependency
> on <linux/math.h>, we calculate space as BITS_PER_LONG-offset;
> - indentation is reduced by not using else-clauses (suggested by
> checkpatch for bitmap_get_value());
> - bitmap_get_value()/bitmap_set_value() are renamed to bitmap_read()
> and bitmap_write();
> - some redundant computations are omitted.
...
> * bitmap_to_arr64(buf, src, nbits) Copy nbits from buf to u64[] dst
> * bitmap_get_value8(map, start) Get 8bit value from map at start
> * bitmap_set_value8(map, value, start) Set 8bit value to map at start
> + * bitmap_read(map, start, nbits) Read an nbits-sized value from
> + * map at start
> + * bitmap_write(map, value, start, nbits) Write an nbits-sized value to
> + * map at start
I still didn't get the grouping you implied with this...
> * Note, bitmap_zero() and bitmap_fill() operate over the region of
> * unsigned longs, that is, bits behind bitmap till the unsigned long
...
> +/**
> + * bitmap_read - read a value of n-bits from the memory region
> + * @map: address to the bitmap memory region
> + * @start: bit offset of the n-bit value
> + * @nbits: size of value in bits, nonzero, up to BITS_PER_LONG
> + *
> + * Returns: value of nbits located at the @start bit offset within the @map
> + * memory region.
> + *
> + * Note: callers on 32-bit systems must be careful to not attempt reading more
> + * than sizeof(unsigned long).
sizeof() here is misleading, We talk about bits, BITS_PER_LONG (which is 32),
here it's better to be explicit that reading more than 32 bits at a time on
32-bit platform will return 0. Actually what you need is to describe...
> + */
> +static inline unsigned long bitmap_read(const unsigned long *map,
> + unsigned long start,
> + unsigned long nbits)
> +{
> + size_t index = BIT_WORD(start);
> + unsigned long offset = start % BITS_PER_LONG;
> + unsigned long space = BITS_PER_LONG - offset;
> + unsigned long value_low, value_high;
> +
> + if (unlikely(!nbits || nbits > BITS_PER_LONG))
> + return 0;
...this return in the Return section.
> +
> + if (space >= nbits)
> + return (map[index] >> offset) & BITMAP_LAST_WORD_MASK(nbits);
> +
> + value_low = map[index] & BITMAP_FIRST_WORD_MASK(start);
> + value_high = map[index + 1] & BITMAP_LAST_WORD_MASK(start + nbits);
> + return (value_low >> offset) | (value_high << space);
> +}
...
> +/**
> + * bitmap_write - write n-bit value within a memory region
> + * @map: address to the bitmap memory region
> + * @value: value to write, clamped to nbits
> + * @start: bit offset of the n-bit value
> + * @nbits: size of value in bits, nonzero, up to BITS_PER_LONG.
> + *
> + * bitmap_write() behaves as-if implemented as @nbits calls of __assign_bit(),
> + * i.e. bits beyond @nbits are ignored:
> + *
> + * for (bit = 0; bit < nbits; bit++)
> + * __assign_bit(start + bit, bitmap, val & BIT(bit));
> + * Note: callers on 32-bit systems must be careful to not attempt writing more
> + * than sizeof(unsigned long).
Ditto.
> + */
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2023-10-26 12:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-25 8:38 [PATCH v9 1/2] lib/bitmap: add bitmap_{read,write}() Alexander Potapenko
2023-10-25 8:38 ` Alexander Potapenko
2023-10-25 8:38 ` [PATCH v9 2/2] lib/test_bitmap: add tests for bitmap_{read,write}() Alexander Potapenko
2023-10-25 8:38 ` Alexander Potapenko
2023-10-26 12:15 ` Andy Shevchenko [this message]
2023-10-26 12:15 ` [PATCH v9 1/2] lib/bitmap: add bitmap_{read,write}() Andy Shevchenko
2023-10-26 12:16 ` Andy Shevchenko
2023-10-26 12:16 ` Andy Shevchenko
2023-10-26 13:28 ` Alexander Potapenko
2023-10-26 13:28 ` Alexander Potapenko
2023-10-26 13:34 ` Andy Shevchenko
2023-10-26 13:34 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZTpYbCa0Qmry0HGH@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=aleksander.lobakin@intel.com \
--cc=alexandru.elisei@arm.com \
--cc=andreyknvl@gmail.com \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=eugenis@google.com \
--cc=glider@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=pcc@google.com \
--cc=syednwaris@gmail.com \
--cc=will@kernel.org \
--cc=william.gray@linaro.org \
--cc=yury.norov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.