linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Yury Norov <yury.norov@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Li Zefan <lizefan@huawei.com>, Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Josh Triplett <josh@joshtriplett.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH 6/8] lib: bitmap: support "N" as an alias for size of bitmap
Date: Wed, 10 Feb 2021 10:58:25 -0500	[thread overview]
Message-ID: <20210210155825.GA28155@windriver.com> (raw)
In-Reply-To: <CAAH8bW_fJi_PeHrXsPZzLtRP=-L99QJBXEvHkN9w6DBP-1FPWQ@mail.gmail.com>

[Re: [PATCH 6/8] lib: bitmap: support "N" as an alias for size of bitmap] On 09/02/2021 (Tue 15:16) Yury Norov wrote:

> On Tue, Feb 9, 2021 at 3:01 PM Paul Gortmaker
> <paul.gortmaker@windriver.com> wrote:

[...]

> >
> > -static const char *bitmap_getnum(const char *str, unsigned int *num)
> > +static const char *bitmap_getnum(const char *str, unsigned int *num,
> > +                                unsigned int lastbit)
> 
> The idea of struct bitmap_region is avoid passing the lastbit to the functions.
> But here you do pass. Can you please be consistent? Or if I misunderstand
> the idea of struct bitmap_region, can you please clarify it?
> 
> Also, I don't think that in this specific case it's worth it to create
> a hierarchy of
> structures. Just adding lastbits to struct region will be simpler and more
> transparent.

I'm getting mixed messages from different people as to what is wanted here.

Here is what the code looks like now; only relevant lines shown:

 -------------------------------
int bitmap_parselist(const char *buf, unsigned long *maskp, int nmaskbits)
{

        struct region r;

        bitmap_parse_region(buf, &r);       <-----------
        bitmap_check_region(&r);
        bitmap_set_region(&r, maskp, nmaskbits);
}

static const char *bitmap_parse_region(const char *str, struct region *r)
{
        bitmap_getnum(str, &r->start);
        bitmap_getnum(str + 1, &r->end);
        bitmap_getnum(str + 1, &r->off);
        bitmap_getnum(str + 1, &r->group_len);
}

static const char *bitmap_getnum(const char *str, unsigned int *num)
{
	/* PG: We need nmaskbits here for N processing. */
}
 -------------------------------


Note the final function - the one where you asked to locate the N
processing into -- does not take a region.  So even if we bundle nbits
into the region struct, it doesn't get the data to where we need it.

Choices:

1) pass in nbits just like bitmap_set_region() does currently.

2) add nbits to region and pass full region instead of start/end/off.

2a) add nbits to region and pass full region and also start/end/off.

3) use *num as a bi-directional data path and initialize with nbits.


Yury doesn't want us add any function args -- i.e. not to do #1.

Andy didn't like #2 because it "hides" that we are writing to r.

I ruled out sending 2a -- bitmap_getnum(str, r, &r->end)  because
it adds an arg, AND seems rather redundant to pass r and r->field.

The #3 is the smallest change - but seems like we are trying to be
too clever just to save a line of code or a couple bytes. (see below)

Yury - in your reply to patch 5, you indicate you wrote the region
code and want me to go back to putting nbits into region directly.

Can you guys please clarify who is maintainer and hence exactly how
you want this relatively minor detail handled?  I'll gladly do it
in whatever way the maintainer wants just to get this finally done.

I'd rather not keep going in circles and guessing and annoying everyone
else on the Cc: list by filling their inbox any more than I already have.

That would help a lot in getting this finished.

Thanks,
Paul.
--

Example #3 -- not sent..

+#define DECLARE_REGION(rname, initval) \
+struct region rname = {                \
+       .start = initval,               \
+       .off = initval,                 \
+       .group_len = initval,           \
+       .end = initval,                 \
+}

[...]

-       struct region r;
+       DECLARE_REGION(r, nmaskbits - 1);       /* "N-N:N/N" */

[...]

+/*
+ * Seeing 'N' tells us to leave the value of "num" unchanged (which will
+ * be the max value for the width of the bitmap, set via DECLARE_REGION).
+ */
 static const char *bitmap_getnum(const char *str, unsigned int *num)
 {
        unsigned long long n;
        unsigned int len;
 
+       if (str[0] == 'N')      /* nothing to do, just advance str */
+               return str + 1;


  reply	other threads:[~2021-02-10 15:59 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09 22:58 [PATCH v4 0/8] support for bitmap (and hence CPU) list "N" abbreviation Paul Gortmaker
2021-02-09 22:59 ` [PATCH 1/8] lib: test_bitmap: clearly separate ERANGE from EINVAL tests Paul Gortmaker
2021-02-09 22:59 ` [PATCH 2/8] lib: test_bitmap: add tests to trigger ERANGE case Paul Gortmaker
2021-02-10 16:27   ` Andy Shevchenko
2021-02-09 22:59 ` [PATCH 3/8] lib: test_bitmap: add more start-end:offset/len tests Paul Gortmaker
2021-02-09 22:59 ` [PATCH 4/8] lib: bitmap: move ERANGE check from set_region to check_region Paul Gortmaker
2021-02-10 16:28   ` Andy Shevchenko
2021-02-09 22:59 ` [PATCH 5/8] lib: bitmap: pair nbits value with region struct Paul Gortmaker
2021-02-10 16:34   ` Andy Shevchenko
2021-02-09 22:59 ` [PATCH 6/8] lib: bitmap: support "N" as an alias for size of bitmap Paul Gortmaker
2021-02-09 23:16   ` Yury Norov
2021-02-10 15:58     ` Paul Gortmaker [this message]
2021-02-10 16:49       ` Andy Shevchenko
2021-02-12  1:24         ` Yury Norov
2021-02-21  8:07           ` Paul Gortmaker
2021-02-09 22:59 ` [PATCH 7/8] lib: test_bitmap: add tests for "N" alias Paul Gortmaker
2021-02-09 22:59 ` [PATCH 8/8] rcu: deprecate "all" option to rcu_nocbs= Paul Gortmaker
2021-02-10 16:26 ` [PATCH v4 0/8] support for bitmap (and hence CPU) list "N" abbreviation Andy Shevchenko
2021-02-10 17:57   ` Paul E. McKenney
2021-02-10 23:50     ` Yury Norov
2021-02-11  0:23       ` Paul E. McKenney
2021-02-12  0:23         ` Yury Norov
2021-02-12  0:38           ` Paul E. McKenney
2021-02-21  8:02       ` Paul Gortmaker
2021-02-11 11:04     ` Rasmus Villemoes
  -- strict thread matches above, loose matches on Subject: below --
2021-02-21  8:08 [PATCH v5 " Paul Gortmaker
2021-02-21  8:08 ` [PATCH 6/8] lib: bitmap: support "N" as an alias for size of bitmap Paul Gortmaker
2021-01-26 17:11 [PATCH v3 0/8] support for bitmap (and hence CPU) list "N" abbreviation Paul Gortmaker
2021-01-26 17:11 ` [PATCH 6/8] lib: bitmap: support "N" as an alias for size of bitmap Paul Gortmaker
2021-01-26 21:37   ` Andy Shevchenko
2021-01-26 21:41     ` Andy Shevchenko
2021-01-27 17:57       ` Yury Norov
2021-01-27  8:20     ` Paul Gortmaker

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=20210210155825.GA28155@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=fweisbec@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=lizefan@huawei.com \
    --cc=mingo@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).