On Sun, 8 Jul 2007 10:31:21 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> There are some ways around this such as using a different workqueue, > one that could safely be blocked during the suspend. This would be the simplest solution, I think. > The user writes to an attribute file. > > The sysfs core calls the attribute's store method. > > The method tells the sysfs core to pretend that the call > temporarily doesn't exist, or has completed, or something > like that. Or add an ignore-for-now-flag to the buffer? It would need to be processed in a second pass. > The method safely unregisters the attribute file, with no > mutual exclusion problems and no deadlock. Of course, the > unregistration will still block until all _other_ method > calls for this attribute are complete. > > The method tells the sysfs core to stop pretending and > go back to its normal state. > > The method returns, and the sysfs core takes whatever actions > are needed to fully release the attribute file. It would need to retain a reference to the buffer collection so it can get rid of the formerly-ignored buffer. > The idea is that there could be a way to allow unregistration while a > method is still running, if the method specifically requests it. If we > could do this then device_schedule_callback() would be unnecessary. > > What do you think? I don't think that this is easy to get correct. Another workqueue looks like a solution which is easy to get right, even if it may not seem so nice. - 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/
