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: Fri, 20 Feb 2009 08:28:42 -0700	[thread overview]
Message-ID: <fa686aa40902200728k1466121cqb772bb9e5d1a777c@mail.gmail.com> (raw)
In-Reply-To: <ac3eb2510902191508w71cf7d76x4a8957ecee9c4e6@mail.gmail.com>

Hi Kay,

Thanks for the reply, it clarifies a lot.  It sounds like this really
should be documented (in Documentation/driver-model/device.txt?).  I'm
happy to add a blurb to that effect and send a patch, but I want to
make sure I really understand the model before I do so.  I've got a
couple more questions below:

On Thu, Feb 19, 2009 at 4:08 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
[...]
> If an attribute is not available at event time, nothing of this can
> ever work. If you look a the device a second later, you will see the
> proper looking files and values, and all the test programs will work,
> but it will always fail at device creation.
[...]
> That all might not be needed for your specific setup/driver/device and
> may work fine for your need. But we don't want to encourage anybody
> with another new API which creates the usual trouble we need to fix
> later.

Fair enough

> And we need to fix things like this all the time.

Can you point me at a 'textbook' example of one of these fixups?

> Also the existing sysfs attribute groups API has the same problem if
> the group is created later, but as far as I can see it should work
> fine for your purpose. So it's better using that, instead of exporting
> another different API.

Okay, I this option looks pretty straight forward too.

Thanks,
g.

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

  reply	other threads:[~2009-02-20 15:28 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
2009-02-19 23:08                     ` Kay Sievers
2009-02-20 15:28                       ` Grant Likely [this message]
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=fa686aa40902200728k1466121cqb772bb9e5d1a777c@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®