From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Sascha Hauer <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: Thu, 20 Feb 2020 13:46:00 +0200 [thread overview]
Message-ID: <CAHp75Vd3KN81qxOWJQ7v=GimSLtVymur_iPsf91pka1STc1nfA@mail.gmail.com> (raw)
In-Reply-To: <20200220105718.eoevd3kb63zzrotu@pengutronix.de>
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:
> > > On Wed, Feb 19, 2020 at 09:50:54PM +0200, Andy Shevchenko wrote:
> > > > On Thu, Feb 13, 2020 at 11:27 AM Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
> > > > >
> > > > > This function is in the same spirit as the other kstrto* functions and
> > > > > uses the same calling convention. It expects the input string to be in
> > > > > the format %u:%u and implements stricter parsing than sscanf as it
> > > > > returns an error on trailing data (other than the usual \n).
> >
> > ...
> >
> > > > On top of that, why kstrtodev_t is so important? How many users are
> > > > already in the kernel to get an advantage out of it?
> > >
> > > Does it need to be important? It matches the other kstrto* functions and
> > > so it seemed more natural to me to put it near the other functions. I'm
> > > not aware of other potential users and surprised you seem to suggest
> > > this as a requirement.
> >
> > Yes it does. The kstrtox() are quite generic, what you are proposing
> > is rather one particular case with blurry understanding how many users
> > will be out of it.
>
> In my understanding one user is a hard requirement.
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/.
> > 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.
> > > > What to do with all other possible variants ("%d:%d", "%dx%d" and its
> > > > %u variant, etc)?
> > >
> > > I don't see how %d:%d is relevant, major and minor cannot be negative
> > > can they? I never saw 'x' as separator between major and minor. I
> > > considered shortly parsing %u, but given that (I think) this is an
> > > internal representation only I chose to not make it more visible than it
> > > already is.
> >
> > 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?
> Also I don't understand yet, what you want me to do.
I have issues with kstrto() not playing with simple numbers (boolean
is a special case, but still a number at the end).
I also don't feel good with too narrow usage of the newly introduced helper
> 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
In b) case, add to the commit message how many potential _existing_
users may be converted to this.
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 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.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2020-02-20 11:46 UTC|newest]
Thread overview: 27+ 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 [this message]
2020-02-20 11:57 ` Andy Shevchenko
2020-02-20 14:01 ` Uwe Kleine-König
2020-02-21 8:42 ` Andy Shevchenko
2020-02-21 10:53 ` Uwe Kleine-König
2020-04-25 7:07 ` Pavel Machek
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='CAHp75Vd3KN81qxOWJQ7v=GimSLtVymur_iPsf91pka1STc1nfA@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
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).