Message-ID: <CAHp75VdD5rJMBqH-YwGKuM5EHUXxeGAon6TfPwq_YxWGzkdrtQ@mail.gmail.com>
Date:   Fri, 21 Feb 2020 10:42:29 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
Cc:     Pengutronix Kernel Team <kernel@...gutronix.de>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>, Jiri Slaby <jslaby@...e.com>,
        Linux LED Subsystem <linux-leds@...r.kernel.org>,
        Dan Murphy <dmurphy@...com>
Subject: Re: [PATCH v6 1/4] lib: new helper kstrtodev_t()

On Thu, Feb 20, 2020 at 4:01 PM Uwe Kleine-König
<u.kleine-koenig@...gutronix.de> wrote:
> On Thu, Feb 20, 2020 at 01:46:00PM +0200, Andy Shevchenko wrote (with
> the additions written in a later mail inserted as if he said them
> already then):
> > On Thu, Feb 20, 2020 at 12:57 PM Uwe Kleine-König
> > <u.kleine-koenig@...gutronix.de> wrote:
> > > On Thu, Feb 20, 2020 at 12:22:36PM +0200, Andy Shevchenko wrote:
> > > > On Thu, Feb 20, 2020 at 9:49 AM Uwe Kleine-König
> > > > <u.kleine-koenig@...gutronix.de> wrote:

...

> > Yes. But looking at the LOCs you introduce to entire kernel in such
> > generic area (I wouldn't tell you anything if, for instance, you
> > introduced a support for hypothetical S2P bus with one host controller
> > driver) like lib/.
>
> Why are added LOCs bad? Increased compile time? Increased binary size?

Both.

> More memory usage when the file is opened in an editor?

Probably in some cases. :-)

> > > > If you had told "look, we have 1234 users which may benefit out of
> > > > it", I would have given no comment against.
> > >
> > > Sure, having >1000 potential users would be a good argument pro this
> > > function. But having only one isn't a good contra IMHO.
> >
> > For lib/ is a good argument in my opinion.
>
> So while I agree (as I wrote) that many users would be great, not having
> many users isn't bad enough to justify putting this function somewhere
> separated from the other kstrto*() functions. I assume we won't be able
> to sort out this difference of opinion.

If you put this like: okay, this is a new helper and new user, but we
have 100500 similar cases in the kernel which may benefit out of this,
it's one story, it you put it like: okay, let's do one helper per each
very particular case, it's another story.
You see the difference? I'm completely against the latter one.

...

> > > > See above, if we are going to make it generic, perhaps better to cover
> > > > more possible users, right?
> > > > Otherwise your change provokes pile of (replaced)
> > > > kstrto_resolution() /* %ux:%u */
> > > > kstrto_range() /* %d:%d */
> > > > kstrto_you_name_it()
> > >
> > > Given there are respective types that this can be stored to, I don't
> > > object more functions of this type and don't see a good reason to not
> > > add such a function. And in my eyes I prefer to have such a function in
> > > a visible place (i.e. where all the other kstrto* functions are) to
> > > prevent code duplication.
> >
> > You can easily satisfy above by adding a function parameter 'char
> > *delim', right?
>
> Well, not completely as major and minor have a different domain range
> compared to unsigned ints (or any other integer type).

Yes, it's also can be adjusted. You provide a better helper and then
you may do something like

static inline ... string_parse_dev_t(...)
{
  ret = string_parse_two_numbers(..., );
  if (ret)
    return ret;

  if (x or y is not in range)
    return -EOVERFLOW;
  ...
}

> > > Also I don't understand yet, what you want me to do.
> >
> > I have issues with kstrto() not playing with simple and single numbers
> > (boolean is a special case, but still a number at the end).
>
> A dev_t is also a number in the end.

My point (when I added single) is 1:1 map. dev_t is not.

> > I also don't feel good with too narrow usage of the newly introduced helper
>
> I don't see how a helper that should provide a valid dev_t and other
> types use a generic function. The specification for parsing a dev_t is:
> "A non-negative number that fits in 20 bits, followed by a colon,
> followed by a non-negative number that fits in 12 bits." So even if we
> had a generic function that could parse (in scanf-semantics) "%u:%u",
> we'd still need a more specialized helper that ensures the range of the
> two integers. (And I suggest to call this helper kstrtodev_t. :-)

See above: 1/ provide a generic helper, 2/ provide its use with
certain dev_t validation.

> > > Assume I'd be
> > > willing to use simple_strtoul, I'd still want to have a function that
> > > gives me a dev_t from a given string. Should I put this directly in my
> > > led-trigger driver?
> >
> > I see the following possibilities:
> > a) put it inside the caller and forget about generic helper
> > b) do a generic helper, but 1/ in string_*() namespace, 2/ with a
> > delimiter parameter and 3/ possibility to take negative numbers
>
> I wonder about 1/. Are there already other (and similar) functions in
> the string_* namespace?

Not exactly. There is a printing in human-readable format for sizes
and escape/unescape.

> IMHO kstrto* is fine. These all take a string
> and provide a value of a given type with strict parsing. As pointed out
> above, 2/ isn't enough. I don't care much about 3/.

See above, I really don't see how this fits kstrtox(), to me it's
obvious layer violation.

> > In b) case, add to the commit message how many potential _existing_
> > users may be converted to this.
>
> <sarcasm>Will use 9f6158946987a5ce3f16da097d18f240a89db417 as a good
> example how to do that.</sarcasm>

I didn't get it. There are _existing_ users in the kernel for that
functionality, At least two are using it right now.
Funny that the original code has been rewritten to get rid of int_pow() call.
You may do the same, i.e. rewrite your code to get rid of whatever_dev_t() use.

> > Also it would be good to have two versions strict (only \n at the end
> > is allowed) and non-strict (based on the amount of users for each
> > group). And don't forget to extend lib/test_string.c accordingly.
> >
> > > > > And given that I was asked for strict
> > > > > parsing (i.e. not accepting 2:4:something) I'd say using simple_strto*
> > > > > is a step backwards. Also simple_strtoul() has "This function is obsolete.
> > > > > Please use kstrtoul instead." in its docstring which seems to apply to
> > > > > the other simple_strto*() functions, too.
> > > >
> > > > I specifically fixed a doc string to approve its use in the precisely
> > > > cases you have here.
> > >
> > > Can you please be a bit more constructive here and point to the change
> > > you talk about? I didn't find a commit in next.
> >
> > https://elixir.bootlin.com/linux/v5.6-rc2/source/include/linux/kernel.h#L446
> >
> > Note, there is no more word 'obsolete' there.
>
> I talked about
>
> https://elixir.bootlin.com/linux/v5.6-rc2/source/lib/vsprintf.c#L61
>
> which still tells to not use it.

I see. Thanks for report, I'll soon send a patch to fix it as well.

> I think what is needed here to satisfy us both is a set of functions like:
>
>         int buftoul(const char *buf, char **endp, unsigned long *result)
>
> which does proper range checking (by not consuming chars that are too
> much) and still provides an endp pointer that allows to make use of this
> function to parse types that are represented by more than a plain
> integer.

Yeah, https://xkcd.com/927/.

> Currently this functionality is provided by _parse_integer
> (with a different API and slightly different semantic). For my purpose
> _parse_integer is good enough, so I'd like to leave introduction and
> identification plus conversion of already existing potential users to
> you.

Nothing prevents you to use it from your parser which will be located
in string_*() namespace.

--
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists