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/
