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 08:48:24 -0700 [thread overview]
Message-ID: <fa686aa40902180748i2d621de1j1da7600e8cc3165f@mail.gmail.com> (raw)
In-Reply-To: <ac3eb2510902180745v2886ae31s2d7faeb2faedab6e@mail.gmail.com>
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.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
next prev parent reply other threads:[~2009-02-18 15:48 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 [this message]
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
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=fa686aa40902180748i2d621de1j1da7600e8cc3165f@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®