From: Grant Likely <grant.likely@secretlab.ca>
To: Greg KH <gregkh@suse.de>
Cc: Kay Sievers <kay.sievers@vrfy.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Export device_add_attributes() so drivers can use it.
Date: Wed, 18 Feb 2009 23:50:46 -0700 [thread overview]
Message-ID: <fa686aa40902182250g1c4e7cb6o4d0102da35ab838b@mail.gmail.com> (raw)
In-Reply-To: <20090218183945.GA31797@suse.de>
On Wed, Feb 18, 2009 at 11:39 AM, Greg KH <gregkh@suse.de> wrote:
> On Wed, Feb 18, 2009 at 07:32:19PM +0100, Kay Sievers wrote:
>> On Wed, Feb 18, 2009 at 18:51, Grant Likely <grant.likely@secretlab.ca> wrote:
>> > Mostly because I have no need another full struct device, and none of
>> > the files that I'm adding have any bearing on udev. They are debug
>> > and statistical files for an embedded system that are used by the
>> > developer. I don't want application code depending on them and I'm
>> > not interested in having them advertised.
>>
>> That's what debugfs is for.
>
> Kay is right, use debugfs for stuff like this. Not sysfs.
>
> So sorry, I'm not going to apply the patch, and you should change your
> code to not open-code this as well.
Forgive my frustration, but I've been happily using sysfs for simple
exports of driver data (not just debug either; for tuning also) for a
while now with no indication that I've doing the wrong thing. I
haven't found anything in Documentation or in LDDv3 that says files
should not be created at probe time. The sysfs API is beautiful to
work with and requires less code than the equivalent debugfs
interface. Often using it exactly matches the use case that I need;
small values, simple settings and safe, concise code.
So, I re-ask my questions:
When is it legal and when is it not legal to call
device_create_file()? If debug only stuff belongs in debugfs, then
fair enough. But what about when tuning controls are needed? If I
have to create a child 'struct device', then I will do so, but I'm
still not convinced on the benefit.
Even then, I'm confused. The KOBJ_ADD uevent is raised at
device_register() time. However, it appear that device_create_file()
often gets called after device_register() (pci_bus_add_child() for
example). What is the cutoff point for calling device_create_file()
so that attributes exist before the uevent (as Kay stated earlier in
this thread)?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
next prev parent reply other threads:[~2009-02-19 6:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-18 15:11 Grant Likely
2009-02-18 15:29 ` Greg KH
2009-02-18 15:45 ` Kay Sievers
2009-02-18 15:48 ` Grant Likely
2009-02-18 15:53 ` Kay Sievers
2009-02-18 16:34 ` Grant Likely
2009-02-18 16:49 ` Kay Sievers
2009-02-18 17:51 ` Grant Likely
2009-02-18 18:32 ` Kay Sievers
2009-02-18 18:39 ` Greg KH
2009-02-18 19:14 ` Kay Sievers
2009-02-19 6:50 ` Grant Likely [this message]
2009-02-19 23:08 ` Kay Sievers
2009-02-20 15:28 ` Grant Likely
2009-02-20 18:35 ` Greg KH
2009-02-26 22:28 ` Kay Sievers
2009-02-26 23:52 ` Grant Likely
2009-02-18 15:46 ` Grant Likely
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=fa686aa40902182250g1c4e7cb6o4d0102da35ab838b@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=gregkh@suse.de \
--cc=kay.sievers@vrfy.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome