mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sebastian Ott <sebott@linux.vnet.ibm.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Greg KH <gregkh@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] bind/unbind uevent
Date: Wed, 8 Dec 2010 11:18:27 +0100 (CET)	[thread overview]
Message-ID: <alpine.LFD.2.02.1012081116530.1909@localhost6.localdomain6> (raw)
In-Reply-To: <AANLkTinmuxDYU9-zGvWB0mDDuXZEfZnuVxtSYGk62c8P@mail.gmail.com>

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.

> 
> Sebastian, care to be more specific about the problem and bus in
> question. We should avoid new generic events. In some special cases,
> sending out 'change' from the driver might be acceptable, but it's
> usually not what we would suggest.

The specific problem I'm facing is about network drivers on S390.
They don't have one network adaptor, but deal with multiple devices
(e.g. a read, write and a data channel). To handle this we create
a group device to combine these devices. Triggered from userspace,
a network driver will create a group device and wait for itself to
bind to it (and adds his attributes inside his probe function).

Now some udev scripts expect these attributes at the time they
receive the add event. I don't want each network driver to throw
their own change events. So I guess I should go for the bus specific
change event. An other option would be to delay the add event..
which would be ugly, but has the advantage that we don't need to
change the udev scripts (which are distributor specific).

Regards,
Sebastian

  reply	other threads:[~2010-12-08 10:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-07 16:18 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 [this message]
2010-12-08 16:02           ` Greg KH
2010-12-13 19:27             ` Sebastian Ott
2010-12-13 19:36               ` Greg KH
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=alpine.LFD.2.02.1012081116530.1909@localhost6.localdomain6 \
    --to=sebott@linux.vnet.ibm.com \
    --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®