On Fri, 9 Mar 2007, Oliver Neukum wrote: > > Adding a new release() callback would solve the problem by creating > > another. Drivers need to release their data as soon as possible after > > they unbind from a device, not when the device itself goes away. Think > > Wait, the callback from closing the file in sysfs is the earliest we can > safely > free the data structure. How do you want to free earlier?
It is _not_ the earliest we can safely free the data structure. Dmitry's callback occurs when _all_ the sysfs attributes have been released -- including ones that don't have anything to do with the driver's private data structure. Think of the bInterfaceClass attribute, for example. But even aside from that, Dmitry's suggestion is wrong. He wants to add a second release() method to the driver, which can be called from the subsystem's release() method -- which doesn't run until the device is unregistered, possibly long after the driver has been unbound from it. Then how could the subsystem even know which drivers need their second release method called? > > Oliver, your idea won't work either. Think about what would happen if > > someone did > > > > rmmod driver_module </sys/devices/.../attribute_file > > -EBUSY, as currently. Yeah, I was wrong about that. > > It might be better to keep your earlier patch and fix the deadlock you > > mentioned earlier, the one that occurs when unbinding a driver through > > sysfs. How exactly does that deadlock work? > > http://lkml.org/lkml/2007/3/6/364 > http://lkml.org/lkml/2007/3/6/528 I get the picture, thanks. Alan Stern - 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/