Messages in this thread | | | Date | Fri, 23 Jan 2004 13:03:33 -0500 (EST) | From | Alan Stern <> | Subject | Re: PATCH: (as177) Add class_device_unregister_wait() and platform_device_unregister_wait() to the driver model core |
| |
On Fri, 23 Jan 2004, Linus Torvalds wrote:
> On Fri, 23 Jan 2004, Alan Stern wrote: > > > > Since I haven't seen any progress towards implementing the > > class_device_unregister_wait() and platform_device_unregister_wait() > > functions, here is my attempt. > > So why would this not deadlock?
Kind of a general question, so I'll give a general answer. This wouldn't deadlock for the same reason as anything else: People use it properly!
> The reason we don't wait on things like this is that it's basically > impossible not to deadlock.
That's an exaggeration. There are places where it's _necessary_ to wait. For example, consider this extract from a recent patch written by Greg KH:
+ /* FIXME change this when the driver core gets the + * class_device_unregister_wait() call */ + init_completion(&bus->released); class_device_unregister(&bus->class_dev); + wait_for_completion(&bus->released);
For the full patch, see http://marc.theaimsgroup.com/?l=linux-usb-devel&m=107109069106188&w=2
The general context is that a module is trying to unload, but it can't until the release() callback for its device has finished.
> There are damn good reasons why the kernel uses reference counting > everywhere. Any other approach is broken.
And sometimes a part of the kernel has to wait until the reference count drops to 0. Instead of making everyone who needs to wait for a class_device or a platform_device roll their own completions, this provides a central facility.
By the way, adding class_device_unregister_wait() has an excellent precedent. The driver model core _already_ includes device_unregister_wait(), merged by Pat Mochel. Are you saying that function shouldn't exist either?
Alan Stern
- 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/
| |