From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org
Subject: Re: [git pull] Input updates for 3.5-rc0
Date: Thu, 24 May 2012 13:59:52 -0700 [thread overview]
Message-ID: <20120524205952.GA16621@core.coreip.homeip.net> (raw)
In-Reply-To: <CA+55aFz9Fp2J=oCkoDAwNTnEJoBeKC9tn+5dqMCKf4C22CAi6Q@mail.gmail.com>
On Thu, May 24, 2012 at 01:48:57PM -0700, Linus Torvalds wrote:
> On Thu, May 24, 2012 at 1:36 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > Hmm, I guess we are better now with cleaning and turning devices into
> > zombies waiting to be reaped.
>
> No, that wasn't the silly part of your statement.
>
> The silly part is that
>
> dev_set_name(&dev->dev, "input-%s", dev_name(dev->dev.parent));
>
> works perfectly fine if the parent goes away, for a damn simple
> reason: it generates the string *once*, and doesn't care one *whit*
> about the parent pointer ever again afterwards.
I was concerned about the _next_ device (the one that will be created
the moment I plug in the tablet back into the same port) having exact
same name as the one that is half dead and clashing in sysfs and
elsewhere. We used to have issues with this.
>
> For exactly the same that your current
>
> dev_set_name(&dev->dev, "input%d", atomic_inc_return(&input_no) - 1);
>
> doesn't care *at*all* about that "input_no" variable afterwards -
> dev_set_name() will have turned it into a string, and "input_no" can
> change as much as it wants, and that won't change the name of the
> device.
and it guarantees to make the name unique, that is all we need.
>
> See? So no "refcounting parents" or "zombie devices" or any crap like
> that. The name is just a string.
>
> Anyway, I can't be bothered to argue. If you think "input1" is such a
> great name, and then that results in nobody actually ever *using* it
> because everybody agrees it useless and will use something else,
> whatever.
>
> Linus
--
Dmitry
next prev parent reply other threads:[~2012-05-24 20:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-24 8:32 [git pull] Input updates for 3.5-rc0 Dmitry Torokhov
2012-05-24 17:33 ` Linus Torvalds
2012-05-24 18:01 ` Dmitry Torokhov
2012-05-24 18:21 ` Linus Torvalds
2012-05-24 19:58 ` Dmitry Torokhov
2012-05-24 20:11 ` Linus Torvalds
2012-05-24 20:36 ` Dmitry Torokhov
2012-05-24 20:48 ` Linus Torvalds
2012-05-24 20:59 ` Dmitry Torokhov [this message]
2012-05-24 21:07 ` Linus Torvalds
2012-05-24 21:38 ` Dmitry Torokhov
2012-05-24 21:56 ` Linus Torvalds
2012-05-24 21:44 ` Linus Torvalds
2012-05-24 21:56 ` Dmitry Torokhov
2012-05-24 21:59 ` Linus Torvalds
2012-05-24 22:01 ` Greg Kroah-Hartman
2012-05-24 22:05 ` Linus Torvalds
2012-05-25 1:39 ` Greg Kroah-Hartman
2012-05-25 19:05 ` Mark Lord
2012-05-24 21:26 ` Greg Kroah-Hartman
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=20120524205952.GA16621@core.coreip.homeip.net \
--to=dmitry.torokhov@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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).