public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Sebastian Ott <sebott@linux.vnet.ibm.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] bind/unbind uevent
Date: Mon, 13 Dec 2010 11:36:17 -0800	[thread overview]
Message-ID: <20101213193617.GA18262@suse.de> (raw)
In-Reply-To: <alpine.LFD.2.02.1012132026430.2013@localhost6.localdomain6>

On Mon, Dec 13, 2010 at 08:27:45PM +0100, Sebastian Ott wrote:
> On Wed, 8 Dec 2010, Greg KH wrote:
> > On Wed, Dec 08, 2010 at 11:18:27AM +0100, Sebastian Ott wrote:
> > > On Tue, 7 Dec 2010, Kay Sievers wrote:
> > > > On Tue, Dec 7, 2010 at 19:33, Greg KH <gregkh@suse.de> wrote:
> > > > > On Tue, Dec 07, 2010 at 06:29:37PM +0100, Sebastian Ott wrote:
> > > > 
> > > > >> So I'm searching for a trigger when these attributes are created, or
> > > > >> in other words when the device is useable, which I think translates to
> > > > >> when a driver is bound to this device.
> > > > >
> > > > > Again, KOBJ_ADD is the correct one.
> > > > >
> > > > > If your driver is creating sysfs attributes on its own, that's a bug and
> > > > > should be fixed.
> > > > 
> > > > Sounds a bit like the driver should create its own child device with
> > > > its own properties, instead of mangling around with attributes at a
> > > > device it binds to.
> > > 
> > > Yes, I get that feeling too. But I'm talking about existing drivers
> > > and I don't think I can change their whole structure.
> > 
> > It's just a matter of putting the attributes in a table and passing that
> > to the bus code the driver registers with.  Only a minor change in the
> > driver is needed to resolve this.
> 
> I don't get it. The current situation is, that our drivers
> add attributes to the device they are about to bind with, in
> the probe function.

Don't do that, have your _driver_ register the attributes with the bus
it is on, then when the binding happens, the attributes will
automatically get created for the device before the notification is sent
to userspace.  That is the proper proceedure here.

> I think we agree that it would be better
> if those drivers would register a child device and add attributes
> to this one. But my concern is that this would break userspace
> which walks the sysfs tree and changes attributes, since it changed
> from:
> /sys/devices/$DEV/$ATTR
> to:
> /sys/devices/$DEV/$CHILD/$ATTR

Ick, no, you don't have to do that, just use the functionality the
driver core provides for you already.

thanks,

greg k-h

  reply	other threads:[~2010-12-13 19:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-07 16:18 [RFC] bind/unbind uevent Sebastian Ott
2010-12-07 16:27 ` Greg KH
2010-12-07 17:29   ` Sebastian Ott
2010-12-07 18:33     ` Greg KH
2010-12-07 19:00       ` Kay Sievers
2010-12-08 10:18         ` Sebastian Ott
2010-12-08 16:02           ` Greg KH
2010-12-13 19:27             ` Sebastian Ott
2010-12-13 19:36               ` Greg KH [this message]
2010-12-14 18:26                 ` Sebastian Ott
2010-12-14 19:29                   ` Greg KH
2010-12-15 13:21                     ` Cornelia Huck
2010-12-15 16:23                       ` Greg KH
2010-12-15 17:35                         ` Cornelia Huck
2010-12-15 17:51                           ` Kay Sievers
2010-12-15 18:08                             ` Cornelia Huck
2010-12-15 18:18                               ` Greg KH
2010-12-16 10:22                                 ` Cornelia Huck
2010-12-08 10:16       ` Sebastian Ott
2010-12-08 16:01         ` Greg KH

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=20101213193617.GA18262@suse.de \
    --to=gregkh@suse.de \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sebott@linux.vnet.ibm.com \
    /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