From: Greg KH <gregkh@linuxfoundation.org>
To: Aniroop Mathur <aniroop.mathur@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-hotplug@vger.kernel.org
Subject: Re: [Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ?
Date: Fri, 01 Aug 2014 22:41:27 +0000 [thread overview]
Message-ID: <20140801224127.GA11596@kroah.com> (raw)
In-Reply-To: <CADYu30_o7rzERKEDe=eZiONp6n1ktMWPydMnXQjDeLrDFQh+vg@mail.gmail.com>
On Sat, Aug 02, 2014 at 03:54:32AM +0530, Aniroop Mathur wrote:
> On Sat, Aug 2, 2014 at 12:53 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Fri, Aug 01, 2014 at 10:43:23PM +0530, Aniroop Mathur wrote:
> >> Dear Mr. Greg Kroah-Hartman and Linux Community,
> >> Greetings of the day !! :)
> >>
> >> I am Aniroop Mathur working on Linux Kernel for last two years.
> >> I am stuck at one point and could not find the solution over internet.
> >> I posted on linuxquestions.org too.
> >> So I need your help and suggestion for it.
> >>
> >> Can you please help in answering my query as below:
> >>
> >> ==========================> >> In function device_add of /drivers/base/core.c file, it is mentioned:
> >> /*
> >> * for statically allocated devices, which should all be converted
> >> * some day, we need to initialize the name. We prevent reading back
> >> * the name, and force the use of dev_name()
> >> */
> >> if (dev->init_name) {
> >> dev_set_name(dev, "%s", dev->init_name);
> >> dev->init_name = NULL;
> >> }
> >>
> >>
> >> Except forcing the use of dev_name to read device name,
> >> Is there any other reason to make init_name as NULL ?
> >
> > Why would you want init_name to not be NULL?
> >
>
> Currently in kernel, we cannot set name of event node.
What do you mean by "event node"?
> If dev->init_name is not set as NULL in device_add(),
> then I can easily set name of event node in evdev_dev.c
> file as below:
>
> if(dev->init_name) {
> sprintf(dev->init_name, "event_%s", dev->init_name);
> }
> error = device_add(&evdev->dev);
>
> And in some input device driver code, I will use like below:
> dev->init_name = "accelerometer";
> input_register_device(dev);
What's wrong with:
dev_set_name(dev, "%s", "accelerometer");
input_register_device(dev);
> So, overall output will be
> /dev/input/event<x> --> /dev/input/event_accelerometer
> sys/class/input/input<x> --> sys/class/input/accelerometer
>
> In short, input and event node names are set just by
> adding one line, which i found quite efficient.
> There is other way also to set name of event node but
> it involves using extra variable and little more code,
> So I am looking for best solution possible. :)
Only use init_name for static struct devices, for a dynamic one, jsut
set the name like everyone else does, how is that "more" code than
anything else?
> >> And if it is not made NULL, is there any problem or side-effect ?
> >
> > Yes, people would start to use it thinking it was the real name of the
> > device, when it might not be.
> >
>
> As the name itself nicely suggests, it is just a initial name.
So please do not use it, someday it will go away...
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Aniroop Mathur <aniroop.mathur@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-hotplug@vger.kernel.org
Subject: Re: [Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ?
Date: Fri, 1 Aug 2014 15:41:27 -0700 [thread overview]
Message-ID: <20140801224127.GA11596@kroah.com> (raw)
In-Reply-To: <CADYu30_o7rzERKEDe=eZiONp6n1ktMWPydMnXQjDeLrDFQh+vg@mail.gmail.com>
On Sat, Aug 02, 2014 at 03:54:32AM +0530, Aniroop Mathur wrote:
> On Sat, Aug 2, 2014 at 12:53 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Fri, Aug 01, 2014 at 10:43:23PM +0530, Aniroop Mathur wrote:
> >> Dear Mr. Greg Kroah-Hartman and Linux Community,
> >> Greetings of the day !! :)
> >>
> >> I am Aniroop Mathur working on Linux Kernel for last two years.
> >> I am stuck at one point and could not find the solution over internet.
> >> I posted on linuxquestions.org too.
> >> So I need your help and suggestion for it.
> >>
> >> Can you please help in answering my query as below:
> >>
> >> =====================================================
> >> In function device_add of /drivers/base/core.c file, it is mentioned:
> >> /*
> >> * for statically allocated devices, which should all be converted
> >> * some day, we need to initialize the name. We prevent reading back
> >> * the name, and force the use of dev_name()
> >> */
> >> if (dev->init_name) {
> >> dev_set_name(dev, "%s", dev->init_name);
> >> dev->init_name = NULL;
> >> }
> >>
> >>
> >> Except forcing the use of dev_name to read device name,
> >> Is there any other reason to make init_name as NULL ?
> >
> > Why would you want init_name to not be NULL?
> >
>
> Currently in kernel, we cannot set name of event node.
What do you mean by "event node"?
> If dev->init_name is not set as NULL in device_add(),
> then I can easily set name of event node in evdev_dev.c
> file as below:
>
> if(dev->init_name) {
> sprintf(dev->init_name, "event_%s", dev->init_name);
> }
> error = device_add(&evdev->dev);
>
> And in some input device driver code, I will use like below:
> dev->init_name = "accelerometer";
> input_register_device(dev);
What's wrong with:
dev_set_name(dev, "%s", "accelerometer");
input_register_device(dev);
> So, overall output will be
> /dev/input/event<x> --> /dev/input/event_accelerometer
> sys/class/input/input<x> --> sys/class/input/accelerometer
>
> In short, input and event node names are set just by
> adding one line, which i found quite efficient.
> There is other way also to set name of event node but
> it involves using extra variable and little more code,
> So I am looking for best solution possible. :)
Only use init_name for static struct devices, for a dynamic one, jsut
set the name like everyone else does, how is that "more" code than
anything else?
> >> And if it is not made NULL, is there any problem or side-effect ?
> >
> > Yes, people would start to use it thinking it was the real name of the
> > device, when it might not be.
> >
>
> As the name itself nicely suggests, it is just a initial name.
So please do not use it, someday it will go away...
thanks,
greg k-h
next prev parent reply other threads:[~2014-08-01 22:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-01 17:13 [Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ? Aniroop Mathur
2014-08-01 17:25 ` Aniroop Mathur
2014-08-01 19:23 ` Greg KH
2014-08-01 19:23 ` Greg KH
2014-08-01 22:24 ` Aniroop Mathur
2014-08-01 22:36 ` Aniroop Mathur
2014-08-01 22:41 ` Greg KH [this message]
2014-08-01 22:41 ` Greg KH
2014-08-01 23:44 ` Aniroop Mathur
2014-08-01 23:56 ` Aniroop Mathur
2014-08-02 2:39 ` Greg KH
2014-08-02 2:39 ` Greg KH
2014-08-03 18:54 ` Aniroop Mathur
2014-08-03 18:54 ` Aniroop Mathur
2014-08-04 4:35 ` Greg KH
2014-08-04 4:35 ` Greg KH
2014-08-04 16:59 ` Aniroop Mathur
2014-08-04 17:11 ` Aniroop Mathur
2014-08-03 16:13 ` Aniroop Mathur
2014-08-03 16:25 ` Aniroop Mathur
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=20140801224127.GA11596@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=aniroop.mathur@gmail.com \
--cc=linux-hotplug@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.