All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yury Norov <yury.norov@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
	linux-arch@vger.kernel.org, linux-sh@vger.kernel.org,
	Alexey Klimov <aklimov@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>, David Sterba <dsterba@suse.com>,
	Dennis Zhou <dennis@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Jianpeng Ma <jianpeng.ma@intel.com>,
	Joe Perches <joe@perches.com>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Rich Felker <dalias@libc.org>,
	Stefano Brivio <sbrivio@redhat.com>,
	Wei Yang <richard.weiyang@linux.alibaba.com>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>
Subject: Re: [PATCH 04/13] lib: introduce BITS_{FIRST,LAST} macro
Date: Tue, 16 Mar 2021 22:40:57 -0700	[thread overview]
Message-ID: <20210317054057.GC2114775@yury-ThinkPad> (raw)
In-Reply-To: <YFCZtUuMYVNeNlUO@smile.fi.intel.com>

On Tue, Mar 16, 2021 at 01:42:45PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 16, 2021 at 09:35:35AM +0100, Rasmus Villemoes wrote:
> > On 16/03/2021 02.54, Yury Norov wrote:
> > > BITMAP_{LAST,FIRST}_WORD_MASK() in linux/bitmap.h duplicates the
> > > functionality of GENMASK(). The scope of BITMAP* macros is wider
> > > than just bitmaps. This patch defines 4 new macros: BITS_FIRST(),
> > > BITS_LAST(), BITS_FIRST_MASK() and BITS_LAST_MASK() in linux/bits.h
> > > on top of GENMASK() and replaces BITMAP_{LAST,FIRST}_WORD_MASK()
> > > to avoid duplication and increase the scope of the macros.
> > > 
> > > This change doesn't affect code generation. On ARM64:
> > > scripts/bloat-o-meter vmlinux.before vmlinux
> > > add/remove: 1/2 grow/shrink: 2/0 up/down: 17/-16 (1)
> > > Function                                     old     new   delta
> > > ethtool_get_drvinfo                          900     908      +8
> > > e843419@0cf2_0001309d_7f0                      -       8      +8
> > > vermagic                                      48      49      +1
> > > e843419@0d45_000138bb_f68                      8       -      -8
> > > e843419@0cc9_00012bce_198c                     8       -      -8
> > 
> > [what on earth are those weird symbols?]
> > 
> > 
> > > diff --git a/include/linux/bits.h b/include/linux/bits.h
> > > index 7f475d59a097..8c191c29506e 100644
> > > --- a/include/linux/bits.h
> > > +++ b/include/linux/bits.h
> > > @@ -37,6 +37,12 @@
> > >  #define GENMASK(h, l) \
> > >  	(GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
> > >  
> > > +#define BITS_FIRST(nr)		GENMASK((nr), 0)
> > > +#define BITS_LAST(nr)		GENMASK(BITS_PER_LONG - 1, (nr))
> > > +
> > > +#define BITS_FIRST_MASK(nr)	BITS_FIRST((nr) % BITS_PER_LONG)
> > > +#define BITS_LAST_MASK(nr)	BITS_LAST((nr) % BITS_PER_LONG)
> > 
> > I don't think it's a good idea to propagate the unusual closed-range
> > semantics of GENMASK to those wrappers. Almost all C and kernel code
> > uses the 'inclusive lower bound, exclusive upper bound', and I'd expect
> > BITS_FIRST(5) to result in a word with five bits set, not six. So I
> > think these changes as-is make the code much harder to read and understand.
> > 
> > Regardless, please add some comments on the valid input ranges to the
> > macros, whether that ends up being 0 <= nr < BITS_PER_LONG or 0 < nr <=
> > BITS_PER_LONG or whatnot.
> > 
> > It would also be much easier to review if you just redefined the
> > BITMAP_LAST_WORD_MASK macros etc. in terms of these new things, so you
> > wouldn't have to do a lot of mechanical changes at the same time as
> > introducing the new ones - especially when those mechanical changes
> > involve adding a "minus 1" everywhere.
> 
> I tend to agree with Rasmus here.

OK. All this plus terrible GENMASK(high, low) design, when high goes
first, makes me feel like we need to deprecate GENMASK and propose a
new interface.

What do you think about this:
BITS_FIRST(bitnum)      -> [0, bitnum)
BITS_LAST(bitnum)       -> [bitnum, BITS_PER_LONG)
BITS_RANGE(begin, end)  -> [begin, end)

We can pick BITS_{LAST,FIRST} implementation from existing BITMAP_*_WORD_MASK
analogues, and make the BITS_RANGE like:
        #define BITS_RANGE(begin, end) BITS_FIRST(end) & BITS_LAST(begin)

Regarding BITMAP_*_WORD_MASK, I can save them in bitmap.h as aliases
to BITS_{LAST,FIRST} to avoid massive renaming. (Should I?)

Would this all work for you?

  reply	other threads:[~2021-03-17  5:41 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-16  1:54 [PATCH v4 00/13] lib/find_bit: fast path for small bitmaps Yury Norov
2021-03-16  1:54 ` [PATCH 01/13] tools: disable -Wno-type-limits Yury Norov
2021-03-16  8:17   ` Rasmus Villemoes
2021-03-16 11:39     ` Andy Shevchenko
2021-03-16  1:54 ` [PATCH 02/13] tools: bitmap: sync function declarations with the kernel Yury Norov
2021-03-16  8:18   ` Rasmus Villemoes
2021-03-16  1:54 ` [PATCH 03/13] arch: rearrange headers inclusion order in asm/bitops for m68k and sh Yury Norov
2021-03-16  1:54 ` [PATCH 04/13] lib: introduce BITS_{FIRST,LAST} macro Yury Norov
2021-03-16  8:35   ` Rasmus Villemoes
2021-03-16 11:42     ` Andy Shevchenko
2021-03-17  5:40       ` Yury Norov [this message]
2021-03-17 19:58         ` Rasmus Villemoes
2021-03-17 23:33           ` Yury Norov
2021-03-16  1:54 ` [PATCH 05/13] tools: sync BITS_MASK macros with the kernel Yury Norov
2021-03-16  1:54 ` [PATCH 06/13] lib: extend the scope of small_const_nbits() macro Yury Norov
2021-03-16  8:56   ` Rasmus Villemoes
2021-03-17  4:53     ` Yury Norov
2021-03-16  1:54 ` [PATCH 07/13] tools: sync small_const_nbits() macro with the kernel Yury Norov
2021-03-16  1:54 ` [PATCH 08/13] lib: inline _find_next_bit() wrappers Yury Norov
2021-03-16  1:54 ` [PATCH 09/13] tools: sync find_next_bit implementation Yury Norov
2021-03-16  1:54 ` [PATCH 10/13] lib: add fast path for find_next_*_bit() Yury Norov
2021-03-16  1:54 ` [PATCH 11/13] lib: add fast path for find_first_*_bit() and find_last_bit() Yury Norov
2021-04-06 16:03   ` Guenter Roeck
2021-04-06 18:15     ` Yury Norov
2021-03-16  1:54 ` [PATCH 12/13] tools: sync lib/find_bit implementation Yury Norov
2021-03-16  1:54 ` [PATCH 13/13] MAINTAINERS: Add entry for the bitmap API Yury Norov
2021-03-16 11:45   ` Andy Shevchenko
2021-03-17  4:47     ` Yury Norov
2021-03-17  4:57       ` Joe Perches
2021-03-17  6:40         ` Lukas Bulwahn
2021-03-17 19:29           ` Yury Norov

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=20210317054057.GC2114775@yury-ThinkPad \
    --to=yury.norov@gmail.com \
    --cc=aklimov@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=dalias@libc.org \
    --cc=dennis@kernel.org \
    --cc=dsterba@suse.com \
    --cc=geert@linux-m68k.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=jianpeng.ma@intel.com \
    --cc=joe@perches.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=richard.weiyang@linux.alibaba.com \
    --cc=sbrivio@redhat.com \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=ysato@users.sourceforge.jp \
    /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.