lkml.org 
[lkml]   [2010]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] bind/unbind uevent
On Wed, 15 Dec 2010 18:51:48 +0100,
Kay Sievers <kay.sievers@vrfy.org> wrote:

> 2010/12/15 Cornelia Huck <cornelia.huck@de.ibm.com>:
> > On Wed, 15 Dec 2010 08:23:16 -0800, Greg KH <gregkh@suse.de> wrote:
> >> On Wed, Dec 15, 2010 at 02:21:13PM +0100, Cornelia Huck wrote:
>
> >> How about I turn it around for you, please show me how the driver core
> >> does _not_ support this today?  If you can prove that this isn't working
> >> properly, then great, I'll gladly accept patches to resolve it.
> >
> > Looking at device_add():
>
> ...
>
> > This will not be a problem if a device driver registers a child device
> > (since it can specify the attributes there).
>
> Which is the proper way to do it. No driver should ever mangle a
> device which it does not own. It's like adding properties of a block
> device directly to a usb_interface device. That just can not work
> correctly for many reasons, inside and outside of the kernel.

That's fine for new device drivers.

>
> > I think the basic problem is that the KOBJ_ADD uevent notifies
> > userspace that "a device is there", while the device will only be
> > really useable by userspace once a driver has bound to it.
>
> This device represents a device on a bus, and can usually do its own
> things. A driver can bind to it, but should not mangle it.
>
> > A module
> > load triggered by KOBJ_ADD is fine, but trying to actually use the
> > device after KOBJ_ADD is racy. This will not matter in the usual case,
> > since either the matching/probing is fast enough or userspace will wait
> > for something like a block device anyway, but we've seen problems on
> > s390. A KOBJ_BIND/UNBIND would make a proper distinction between
> > "device is there" and "device is usable".
>
> We don't rally want any such events. We expect a new child device
> being created from the driver, instead of re-using the existing bus
> device.

Do we want to force a device driver to create a child device just to
notify userspace of the bind?

>
> > (Besides, what happens on unbind/bind? Shouldn't userspace know that a
> > device is now bound to a different driver?)
>
> It does that by watching the child devices the driver creates and destroys.
>
> We already have enough events to handle on today's boxes, we really
> don't want to add new ones, which are only needed to work around such
> use cases, which ideally just should be fixed.
>
> If you can not change the current drivers to create child devices, the
> driver can probably just send change events for the already existing
> devices it mangles from the driver.

Since introducing child devices would change the userspace interface, a
change event on BUS_NOTIFY_BOUND_DRIVER would probably be the most
reasonable for our busses.

>
> We don't want to encourage any such use model in general, and such
> hacks should be bus/driver specific (and only for legacy reasons), and
> they do not belong into the driver core.

At the end of the day, we just want a working system :)

Cornelia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2010-12-15 19:11    [W:0.052 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site