[lkml]   [2007]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH RFD] alternative kobject release wait mechanism
    On Tue, 24 Apr 2007 15:38:12 -0400 (EDT),
    Alan Stern <> wrote:

    > We ought to make it explicitly clear that _all_ subsystems should behave
    > this way. Maybe it isn't necessary to go as far as having device_del()
    > call itself recursively; doing that would open up lots of possible races.
    > But I think it would be a good idea to add a WARN_ON in device_del, right
    > after the call to bus_remove_device(), that would be triggered if the
    > device still had any children.

    If we decide that this should be policy, WARN_ON may be the least
    invasive option.

    Should it be a possible option to move children to a different parent,
    so that the requirement wouldn't be "unregister all children", but "no
    children remain after remove() returns"?

    > It would also be good to document (but where?) some lifetime rules for
    > device drivers.


    > Something like this:
    > When a driver's remove() method returns, the driver must no
    > longer try to use the device it was just unbound from. The
    > device may be physically gone, or a different driver may be
    > bound to it. Most importantly, remove() should unregister
    > all child devices created by the driver.

    s/should/must/, if we agree on the policy above.

    The remove() method must also unset driver_data.

    > To accomplish all this safely, the driver should allocate a
    > private data structure containing at least a "gone" flag and
    > a mutex or spinlock for synchronization. Each time the driver
    > needs to use the device, it should first lock the mutex or
    > spinlock and check the "gone" flag.

    How should a driver make the device -> private data transition if it
    may no longer have private data attached to the device?

    > Ideally remove() should release all of the driver's references
    > to the device, in accord with the "Immediate Detach" principle.
    > However it is acceptable for the driver to retain a reference,
    > provided it meets the following conditions:
    > The reference must be dropped in a timely manner,
    > such as when the release() methods for all child
    > devices have run.
    > The driver must also retain a module reference to
    > the owner of the device. In practice this means the
    > driver must contain static code references to the
    > subsystem which created the device, since struct
    > device doesn't have an "owner" field.

    Uhm. This would imply that a driver may never create a device itself.
    However, the kobject->owner and module refcounting stuff should remove
    this restriction.

    > The driver must restrict itself to reading (not
    > writing!) the fields in the device structure. The
    > only exception is that the driver may lock/unlock
    > dev->sem.

    And it may decrease the reference count, of course :)

    > How does that sound?

    Yes, we should have some documentation like that.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-04-25 11:01    [W:0.027 / U:17.552 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site