[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa686aa40902180748i2d621de1j1da7600e8cc3165f@mail.gmail.com>
Date: Wed, 18 Feb 2009 08:48:24 -0700
From: Grant Likely <grant.likely@...retlab.ca>
To: Kay Sievers <kay.sievers@...y.org>
Cc: Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Export device_add_attributes() so drivers can use it.
On Wed, Feb 18, 2009 at 8:45 AM, Kay Sievers <kay.sievers@...y.org> wrote:
> On Wed, Feb 18, 2009 at 16:29, Greg KH <gregkh@...e.de> wrote:
>> On Wed, Feb 18, 2009 at 08:11:34AM -0700, Grant Likely wrote:
>>> From: Grant Likely <grant.likely@...retlab.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists