All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: bitmap API consistency
Date: Tue, 19 Dec 2017 19:32:36 +0200	[thread overview]
Message-ID: <1513704756.7000.209.camel@linux.intel.com> (raw)
In-Reply-To: <1495629805.6967.101.camel@linux.intel.com>

On Wed, 2017-05-24 at 15:43 +0300, Andy Shevchenko wrote:
> On Wed, 2017-05-24 at 14:38 +0200, Rasmus Villemoes wrote:
> > On 24 May 2017 at 14:11, Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > Hi!
> > > 
> > > Surprisingly discovered today that bitmap API is not consistent in
> > > some
> > > cases (at least one I found recently).
> > > 
> > > bitmap_fill() sets area of bits in a bitmap.
> > > bitmap_zero() clears them.
> > > 
> > > However, if _fill() does something sane, _zero() clears _all_ bits
> > > up to
> > > word size (long).
> > > 
> > > I think it should be fixed to be consistent with _fill() variant.
> > 
> > What do you want it to do?
> 
> Based on my vision and your answer below, thanks for it, I think we
> need
> to
> a) make _fill() to fill entire _aligned_ area
> b) update comments in the header and documentation, if needed, to
> specify that _fill() / _zero() operates on aligned to word size area,
> while _set() and _clear() do exact amount of bits.

7 months passed, can we eventually do something about it?

> >  It always acts on whole words, so the last
> > word must be set to something. One might as well say that _zero and
> > _fill are consistent in that they both set the bits beyond nbits in
> > the last word to 0.
> > 
> > If anything, I'd change bitmap_fill to do a memset(0xff) of the
> > entire
> > region. There used to be bugs where some of the bitmap_* functions
> > didn't actually ignore the trailing bits, making it somewhat
> > important
> > that they were always 0, but I think they're fixed now.
> > 
> > Note that if one wants a guarantee that the trailing bits are not
> > touched at all, the APIs to use are bitmap_{set, clear}(dst, 0,
> > count). bitmap_{zero,fill} assumes that nbits is the total size of
> > the
> > bitmap (i.e. that the user will never care about bits beyond nbits).
> > Maybe a few comments could be added somewhere.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

      reply	other threads:[~2017-12-19 17:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-24 12:11 bitmap API consistency Andy Shevchenko
2017-05-24 12:38 ` Rasmus Villemoes
2017-05-24 12:43   ` Andy Shevchenko
2017-12-19 17:32     ` Andy Shevchenko [this message]

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=1513704756.7000.209.camel@linux.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=schwidefsky@de.ibm.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.