All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yury Norov <yury.norov@gmail.com>
To: Herve Codina <herve.codina@bootlin.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Vadim Fedorenko <vadim.fedorenko@linux.dev>,
	netdev@vger.kernel.org,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	linux-kernel@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
	Mark Brown <broonie@kernel.org>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	linuxppc-dev@lists.ozlabs.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v3 RESEND 4/6] bitmap: Introduce bitmap_off()
Date: Mon, 12 Feb 2024 10:41:42 -0800	[thread overview]
Message-ID: <ZcpmZh8td8DNFzin@yury-ThinkPad> (raw)
In-Reply-To: <ZcplW2mXObOZUtR7@yury-ThinkPad>

On Mon, Feb 12, 2024 at 10:37:18AM -0800, Yury Norov wrote:
> On Mon, Feb 12, 2024 at 08:56:32AM +0100, Herve Codina wrote:
> > The bitmap_onto() function translates one bitmap relative to another but
> > no function are present to perform the reverse translation.
> > 
> > Introduce bitmap_off() to fill this hole.
> > 
> > Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> > ---
> >  include/linux/bitmap.h |  3 +++
> >  lib/bitmap.c           | 42 ++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 45 insertions(+)
> > 
> > diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
> > index 99451431e4d6..5ecfcbbc91f4 100644
> > --- a/include/linux/bitmap.h
> > +++ b/include/linux/bitmap.h
> > @@ -65,6 +65,7 @@ struct device;
> >   *  bitmap_remap(dst, src, old, new, nbits)     *dst = map(old, new)(src)
> >   *  bitmap_bitremap(oldbit, old, new, nbits)    newbit = map(old, new)(oldbit)
> >   *  bitmap_onto(dst, orig, relmap, nbits)       *dst = orig relative to relmap
> > + *  bitmap_off(dst, orig, relmap, nbits)        *dst = bitmap_onto() reverse operation
> >   *  bitmap_fold(dst, orig, sz, nbits)           dst bits = orig bits mod sz
> >   *  bitmap_parse(buf, buflen, dst, nbits)       Parse bitmap dst from kernel buf
> >   *  bitmap_parse_user(ubuf, ulen, dst, nbits)   Parse bitmap dst from user buf
> > @@ -208,6 +209,8 @@ int bitmap_bitremap(int oldbit,
> >  		const unsigned long *old, const unsigned long *new, int bits);
> >  void bitmap_onto(unsigned long *dst, const unsigned long *orig,
> >  		const unsigned long *relmap, unsigned int bits);
> > +void bitmap_off(unsigned long *dst, const unsigned long *orig,
> > +		const unsigned long *relmap, unsigned int bits);
> >  void bitmap_fold(unsigned long *dst, const unsigned long *orig,
> >  		unsigned int sz, unsigned int nbits);
> >  
> > diff --git a/lib/bitmap.c b/lib/bitmap.c
> > index 2feccb5047dc..71343967335e 100644
> > --- a/lib/bitmap.c
> > +++ b/lib/bitmap.c
> > @@ -682,6 +682,48 @@ void bitmap_onto(unsigned long *dst, const unsigned long *orig,
> >  }
> >  EXPORT_SYMBOL(bitmap_onto);
> >  
> > +/**
> > + * bitmap_off - revert operation done by bitmap_onto()
> 
> This is definitely a bad name. I've no a better idea, but even
> bitmap_onto_revert() would be better.
> 
> > + *     @dst: resulting translated bitmap
> > + *     @orig: original untranslated bitmap
> > + *     @relmap: bitmap relative to which translated
> > + *     @bits: number of bits in each of these bitmaps
> > + *
> > + * Suppose onto computed using bitmap_onto(onto, src, relmap, n)
> > + * The operation bitmap_off(result, onto, relmap, n) leads to a
> > + * result equal or equivalent to src.
> 
> Agree with Rasmus. This should be well tested.
> 
> > + * The result can be 'equivalent' because bitmap_onto() and
> > + * bitmap_off() are not bijective.
> > + * The result and src values are equivalent in that sense that a
> > + * call to bitmap_onto(onto, src, relmap, n) and a call to
> > + * bitmap_onto(onto, result, relmap, n) will lead to the same onto
> > + * value.
> 
> Did you mean "a call to bitmap_onto(onto, src, relmap, n) and a
> call to bitmap_off(onto, result, relmap, n)"? 
> 
> I think the whole paragraph adds more confusion than explanations.
> If a new function is supposed to revert the result of some other
> function, I'd better focus on testing that it actually reverts as
> advertised, and keep description as brief as possible.
> 
> > + * If either of @orig or @relmap is empty (no set bits), then @dst
> > + * will be returned empty.
> 
> Is this an exception from the 'revert' policy? Doesn't look like that.
> So, what for mentioning this specific case?
> 
> > + * All bits in @dst not set by the above rule are cleared.
> 
> The above rule is about empty @orig and @relmap, not about setting
> bits. What did you mean here?
> 
> > + */
> > +void bitmap_off(unsigned long *dst, const unsigned long *orig,
> > +		const unsigned long *relmap, unsigned int bits)
> > +{
> > +	unsigned int n, m;      /* same meaning as in above comment */
> 
> In the above comment, n means the size of bitmaps, and m is not
> mentioned at all.
> 
> > +	if (dst == orig)        /* following doesn't handle inplace mappings */
> > +		return;
> > +	bitmap_zero(dst, bits);
> 
> Can you add an empty line after 'return'.
> 
> > +	m = 0;
> > +	for_each_set_bit(n, relmap, bits) {
> > +		/* m == bitmap_pos_to_ord(relmap, n, bits) */
> 
> Don't think we need this comment here. If you want to underline that
> m tracks bit order, can you just give it a more explanatory name. For
> example, 'bit_order'.
> 
> > +		if (test_bit(n, orig))
> > +			set_bit(m, dst);
> > +		m++;

Forgot to mention - we need a __set_bit() and __test_bit(), because the
whole function is not atomic. This applies to the bitmap_onto() as
well. Can you please send a patch fixing it for bitmap_onto() in the
next iteration?

> > +	}
> > +}
> > +EXPORT_SYMBOL(bitmap_off);
> > +
> >  #ifdef CONFIG_NUMA
> >  /**
> >   * bitmap_fold - fold larger bitmap into smaller, modulo specified size
> > -- 
> > 2.43.0

WARNING: multiple messages have this Message-ID (diff)
From: Yury Norov <yury.norov@gmail.com>
To: Herve Codina <herve.codina@bootlin.com>
Cc: Vadim Fedorenko <vadim.fedorenko@linux.dev>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, Andrew Lunn <andrew@lunn.ch>,
	Mark Brown <broonie@kernel.org>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v3 RESEND 4/6] bitmap: Introduce bitmap_off()
Date: Mon, 12 Feb 2024 10:41:42 -0800	[thread overview]
Message-ID: <ZcpmZh8td8DNFzin@yury-ThinkPad> (raw)
In-Reply-To: <ZcplW2mXObOZUtR7@yury-ThinkPad>

On Mon, Feb 12, 2024 at 10:37:18AM -0800, Yury Norov wrote:
> On Mon, Feb 12, 2024 at 08:56:32AM +0100, Herve Codina wrote:
> > The bitmap_onto() function translates one bitmap relative to another but
> > no function are present to perform the reverse translation.
> > 
> > Introduce bitmap_off() to fill this hole.
> > 
> > Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> > ---
> >  include/linux/bitmap.h |  3 +++
> >  lib/bitmap.c           | 42 ++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 45 insertions(+)
> > 
> > diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
> > index 99451431e4d6..5ecfcbbc91f4 100644
> > --- a/include/linux/bitmap.h
> > +++ b/include/linux/bitmap.h
> > @@ -65,6 +65,7 @@ struct device;
> >   *  bitmap_remap(dst, src, old, new, nbits)     *dst = map(old, new)(src)
> >   *  bitmap_bitremap(oldbit, old, new, nbits)    newbit = map(old, new)(oldbit)
> >   *  bitmap_onto(dst, orig, relmap, nbits)       *dst = orig relative to relmap
> > + *  bitmap_off(dst, orig, relmap, nbits)        *dst = bitmap_onto() reverse operation
> >   *  bitmap_fold(dst, orig, sz, nbits)           dst bits = orig bits mod sz
> >   *  bitmap_parse(buf, buflen, dst, nbits)       Parse bitmap dst from kernel buf
> >   *  bitmap_parse_user(ubuf, ulen, dst, nbits)   Parse bitmap dst from user buf
> > @@ -208,6 +209,8 @@ int bitmap_bitremap(int oldbit,
> >  		const unsigned long *old, const unsigned long *new, int bits);
> >  void bitmap_onto(unsigned long *dst, const unsigned long *orig,
> >  		const unsigned long *relmap, unsigned int bits);
> > +void bitmap_off(unsigned long *dst, const unsigned long *orig,
> > +		const unsigned long *relmap, unsigned int bits);
> >  void bitmap_fold(unsigned long *dst, const unsigned long *orig,
> >  		unsigned int sz, unsigned int nbits);
> >  
> > diff --git a/lib/bitmap.c b/lib/bitmap.c
> > index 2feccb5047dc..71343967335e 100644
> > --- a/lib/bitmap.c
> > +++ b/lib/bitmap.c
> > @@ -682,6 +682,48 @@ void bitmap_onto(unsigned long *dst, const unsigned long *orig,
> >  }
> >  EXPORT_SYMBOL(bitmap_onto);
> >  
> > +/**
> > + * bitmap_off - revert operation done by bitmap_onto()
> 
> This is definitely a bad name. I've no a better idea, but even
> bitmap_onto_revert() would be better.
> 
> > + *     @dst: resulting translated bitmap
> > + *     @orig: original untranslated bitmap
> > + *     @relmap: bitmap relative to which translated
> > + *     @bits: number of bits in each of these bitmaps
> > + *
> > + * Suppose onto computed using bitmap_onto(onto, src, relmap, n)
> > + * The operation bitmap_off(result, onto, relmap, n) leads to a
> > + * result equal or equivalent to src.
> 
> Agree with Rasmus. This should be well tested.
> 
> > + * The result can be 'equivalent' because bitmap_onto() and
> > + * bitmap_off() are not bijective.
> > + * The result and src values are equivalent in that sense that a
> > + * call to bitmap_onto(onto, src, relmap, n) and a call to
> > + * bitmap_onto(onto, result, relmap, n) will lead to the same onto
> > + * value.
> 
> Did you mean "a call to bitmap_onto(onto, src, relmap, n) and a
> call to bitmap_off(onto, result, relmap, n)"? 
> 
> I think the whole paragraph adds more confusion than explanations.
> If a new function is supposed to revert the result of some other
> function, I'd better focus on testing that it actually reverts as
> advertised, and keep description as brief as possible.
> 
> > + * If either of @orig or @relmap is empty (no set bits), then @dst
> > + * will be returned empty.
> 
> Is this an exception from the 'revert' policy? Doesn't look like that.
> So, what for mentioning this specific case?
> 
> > + * All bits in @dst not set by the above rule are cleared.
> 
> The above rule is about empty @orig and @relmap, not about setting
> bits. What did you mean here?
> 
> > + */
> > +void bitmap_off(unsigned long *dst, const unsigned long *orig,
> > +		const unsigned long *relmap, unsigned int bits)
> > +{
> > +	unsigned int n, m;      /* same meaning as in above comment */
> 
> In the above comment, n means the size of bitmaps, and m is not
> mentioned at all.
> 
> > +	if (dst == orig)        /* following doesn't handle inplace mappings */
> > +		return;
> > +	bitmap_zero(dst, bits);
> 
> Can you add an empty line after 'return'.
> 
> > +	m = 0;
> > +	for_each_set_bit(n, relmap, bits) {
> > +		/* m == bitmap_pos_to_ord(relmap, n, bits) */
> 
> Don't think we need this comment here. If you want to underline that
> m tracks bit order, can you just give it a more explanatory name. For
> example, 'bit_order'.
> 
> > +		if (test_bit(n, orig))
> > +			set_bit(m, dst);
> > +		m++;

Forgot to mention - we need a __set_bit() and __test_bit(), because the
whole function is not atomic. This applies to the bitmap_onto() as
well. Can you please send a patch fixing it for bitmap_onto() in the
next iteration?

> > +	}
> > +}
> > +EXPORT_SYMBOL(bitmap_off);
> > +
> >  #ifdef CONFIG_NUMA
> >  /**
> >   * bitmap_fold - fold larger bitmap into smaller, modulo specified size
> > -- 
> > 2.43.0

  reply	other threads:[~2024-02-12 18:42 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-12  7:56 [PATCH v3 RESEND 0/6] Add support for QMC HDLC Herve Codina
2024-02-12  7:56 ` Herve Codina
2024-02-12  7:56 ` [PATCH v3 RESEND 1/6] net: wan: " Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12 12:22   ` Andy Shevchenko
2024-02-12 12:22     ` Andy Shevchenko
2024-02-22 12:05     ` Herve Codina
2024-02-22 12:05       ` Herve Codina
2024-02-22 13:19       ` Andy Shevchenko
2024-02-22 13:19         ` Andy Shevchenko
2024-02-22 13:21         ` Herve Codina
2024-02-22 13:21           ` Herve Codina
2024-02-12  7:56 ` [PATCH v3 RESEND 2/6] MAINTAINERS: Add the Freescale QMC HDLC driver entry Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [PATCH v3 RESEND 3/6] bitmap: Make bitmap_onto() available to users Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12 12:27   ` Andy Shevchenko
2024-02-12 12:27     ` Andy Shevchenko
2024-02-12 13:37     ` Herve Codina
2024-02-12 13:37       ` Herve Codina
2024-02-12 14:01       ` Andy Shevchenko
2024-02-12 14:01         ` Andy Shevchenko
2024-02-12 14:20         ` Herve Codina
2024-02-12 14:20           ` Herve Codina
2024-02-12 14:36           ` Andy Shevchenko
2024-02-12 14:36             ` Andy Shevchenko
2024-02-12 19:13             ` Yury Norov
2024-02-12 19:13               ` Yury Norov
2024-02-15 17:46               ` Herve Codina
2024-02-15 17:46                 ` Herve Codina
2024-02-15 19:17                 ` Andy Shevchenko
2024-02-15 19:17                   ` Andy Shevchenko
2024-02-21 13:44                   ` Herve Codina
2024-02-21 13:44                     ` Herve Codina
2024-02-21 14:30                     ` Andy Shevchenko
2024-02-21 14:30                       ` Andy Shevchenko
2024-02-12  7:56 ` [PATCH v3 RESEND 4/6] bitmap: Introduce bitmap_off() Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  9:45   ` Rasmus Villemoes
2024-02-12  9:45     ` Rasmus Villemoes
2024-02-12 18:37   ` Yury Norov
2024-02-12 18:37     ` Yury Norov
2024-02-12 18:41     ` Yury Norov [this message]
2024-02-12 18:41       ` Yury Norov
2024-02-12  7:56 ` [PATCH v3 RESEND 5/6] net: wan: fsl_qmc_hdlc: Add runtime timeslots changes support Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [PATCH v3 RESEND 6/6] net: wan: fsl_qmc_hdlc: Add framer support Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [RESEND PATCH v3 0/6] Add support for QMC HDLC Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [RESEND PATCH v3 1/6] net: wan: " Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [RESEND PATCH v3 2/6] MAINTAINERS: Add the Freescale QMC HDLC driver entry Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [RESEND PATCH v3 3/6] bitmap: Make bitmap_onto() available to users Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [RESEND PATCH v3 4/6] bitmap: Introduce bitmap_off() Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [RESEND PATCH v3 5/6] net: wan: fsl_qmc_hdlc: Add runtime timeslots changes support Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [RESEND PATCH v3 6/6] net: wan: fsl_qmc_hdlc: Add framer support Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  8:05 ` [PATCH v3 RESEND 0/6] Add support for QMC HDLC Herve Codina
2024-02-12  8:05   ` Herve Codina

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=ZcpmZh8td8DNFzin@yury-ThinkPad \
    --to=yury.norov@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=herve.codina@bootlin.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vadim.fedorenko@linux.dev \
    /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.