mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Greg KH <gregkh@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Export device_add_attributes() so drivers can use it.
Date: Wed, 18 Feb 2009 09:34:09 -0700	[thread overview]
Message-ID: <fa686aa40902180834r2b9b8de0tcdc31c850f6323a6@mail.gmail.com> (raw)
In-Reply-To: <ac3eb2510902180753l5dc94e5dje9154eaea9d2db29@mail.gmail.com>

On Wed, Feb 18, 2009 at 8:53 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Wed, Feb 18, 2009 at 16:48, Grant Likely <grant.likely@secretlab.ca> wrote:
>> On Wed, Feb 18, 2009 at 8:45 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>>> On Wed, Feb 18, 2009 at 16:29, Greg KH <gregkh@suse.de> wrote:
>>>> On Wed, Feb 18, 2009 at 08:11:34AM -0700, Grant Likely wrote:
>>>>> From: Grant Likely <grant.likely@secretlab.ca>
>>>>>
>>>>> I find myself using the pattern of device_add_attributes() and
>>>>> device_remove_attributes() frequently in my drivers.  Rather than
>>>>> reinventing the wheel every time, I'm floating this patch to export
>>>>> the symbols to see how it is received.  If this looks okay then I'll
>>>>> rework my drivers and post additional patches to use these functions.
>>>>
>>>> No objection from me, as long as the symbols are EXPORT_SYMBOL_GPL(),
>>>> like the rest of the driver core.  Is that ok with you?
>>>
>>> These functions used outside the core create attributes after the
>>> uevent is sent, and userspace will not see these files at event time.
>>> This is in most cases a pretty broken behavior. Is that the expected
>>> behavior in your drivers?
>>
>> ??? I don't follow what you mean.
>>
>> I'm using these functions to allow the driver to add device attribs;
>> primarily for debugging knobs and controls.  Userspace will see the
>> files after the driver is bound to the device.  The uevent doesn't
>> really come into play.
>
> Sure, they do. Many things expect all files which are visible at the
> device to be readable also at event time. That's the whole way udev
> and device property matching works. There are only a few exceptions
> where creating files at a device later, after it is registered with
> the core, is not a bug.

Let me make sure I understand you...

Is it a bug for a device driver to call
device_create_file()/device_remove_file() at probe time?  For example,
if I have a data capture device which is probed via the platform bus,
is it okay for the .probe() function for the driver to use
device_create_file() to add a 'rate_statistics' file which dumps out
some data rate statistics in ASCII form?

I was under the impression that
device_create_file()/device_remove_file() were okay to use at probe
time.  device_add_attributes()/device_remove_attributes() are only
wrappers around device_create_file()/device_remove_file() with error
checking and unwinding when things go wrong.

Am I incorrect here?

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

  reply	other threads:[~2009-02-18 16:34 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 [this message]
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
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=fa686aa40902180834r2b9b8de0tcdc31c850f6323a6@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

all inboxes | Powered by JetHome®