On Tue, 24 Apr 2007 15:38:12 -0400 (EDT),
Alan Stern <[email protected]> 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.
Documentation/driver-model/lifetime-rules.txt?
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
