Linux-LEDs Archive on lore.kernel.org
 help / color / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>,
	"open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Pavel Machek <pavel@ucw.cz>, Jiri Slaby <jslaby@suse.com>,
	Linux LED Subsystem <linux-leds@vger.kernel.org>,
	Dan Murphy <dmurphy@ti.com>
Subject: Re: [PATCH v6 1/4] lib: new helper kstrtodev_t()
Date: Fri, 21 Feb 2020 10:42:29 +0200
Message-ID: <CAHp75VdD5rJMBqH-YwGKuM5EHUXxeGAon6TfPwq_YxWGzkdrtQ@mail.gmail.com> (raw)
In-Reply-To: <20200220140101.frlxklnv6x3uhzow@pengutronix.de>

On Thu, Feb 20, 2020 at 4:01 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.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@pengutronix.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@pengutronix.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

  reply index

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-13  9:15 [PATCH v6 0/4] leds: trigger: implement a tty trigger Uwe Kleine-König
2020-02-13  9:15 ` [PATCH v6 1/4] lib: new helper kstrtodev_t() Uwe Kleine-König
2020-02-19 19:50   ` Andy Shevchenko
2020-02-20  7:49     ` Uwe Kleine-König
2020-02-20 10:22       ` Andy Shevchenko
2020-02-20 10:57         ` Uwe Kleine-König
2020-02-20 11:46           ` Andy Shevchenko
2020-02-20 11:57             ` Andy Shevchenko
2020-02-20 14:01             ` Uwe Kleine-König
2020-02-21  8:42               ` Andy Shevchenko [this message]
2020-02-21 10:53                 ` Uwe Kleine-König
2020-02-13  9:15 ` [PATCH v6 2/4] tty: rename tty_kopen() and add new function tty_kopen_shared() Uwe Kleine-König
2020-02-19 13:21   ` Johan Hovold
2020-02-19 16:37     ` Uwe Kleine-König
2020-02-19 17:17       ` Johan Hovold
2020-02-20 11:04         ` Uwe Kleine-König
2020-02-25  8:55           ` Johan Hovold
2020-02-25  9:05             ` Uwe Kleine-König
2020-02-13  9:15 ` [PATCH v6 3/4] tty: new helper function tty_get_icount() Uwe Kleine-König
2020-02-13  9:16 ` [PATCH v6 4/4] leds: trigger: implement a tty trigger Uwe Kleine-König
2020-02-19 10:52   ` Johan Hovold
2020-02-19 11:03     ` Uwe Kleine-König
2020-02-19 11:19       ` Johan Hovold
2020-02-19 12:48         ` Johan Hovold
2020-02-19 10:40 ` [PATCH v6 0/4] " Greg Kroah-Hartman
2020-02-26 14:02   ` Pavel Machek

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=CAHp75VdD5rJMBqH-YwGKuM5EHUXxeGAon6TfPwq_YxWGzkdrtQ@mail.gmail.com \
    --to=andy.shevchenko@gmail.com \
    --cc=dmurphy@ti.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=jslaby@suse.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=u.kleine-koenig@pengutronix.de \
    /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

Linux-LEDs Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-leds/0 linux-leds/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-leds linux-leds/ https://lore.kernel.org/linux-leds \
		linux-leds@vger.kernel.org
	public-inbox-index linux-leds

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-leds


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git