lkml.org 
[lkml]   [2010]   [Dec]   [16]   [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 10:18:54 -0800,
    Greg KH <gregkh@suse.de> wrote:

    > On Wed, Dec 15, 2010 at 07:08:44PM +0100, Cornelia Huck wrote:
    > > 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.
    >
    > No, that's for _all_ drivers, why should yours be "special" and not work
    > this way?

    Because it would break existing userspace.

    >
    > > > > 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?
    >
    > That's the way all other buses and drivers work, again, why are your
    > devices and drivers "special" here?

    ?? This has nothing to do with our drivers. Why should a generic driver
    that doesn't need extra attributes etc. create a child device? (Well,
    if that's the way it's supposed to work...)

    >
    > > > > (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.
    >
    > No, you _already_ get those events, and you can add attributes
    > automatically when that happens today!

    But it is still _after_ the KOBJ_ADD uevent, which makes it still racy,
    regardless of who adds the attributes. (And of course we would only do
    the change event for our busses, not for everyone.)

    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-16 11:25    [W:0.028 / U:89.672 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site