Messages in this thread | | | Date | Sun, 8 Jul 2007 10:31:21 -0400 (EDT) | From | Alan Stern <> | Subject | Sysfs and suicidal attributes |
| |
Tejun:
You remember the problem we faced with "suicidal" sysfs attributes and the device_schedule_callback() routine that fixes it?
Well, it turns out that this approach may confict with suspend/resume processing. In brief, it's not a good idea to unregister devices while a suspend is in progress, but on the other hand it's not a good idea to block keventd waiting until the suspend is over.
There are some ways around this such as using a different workqueue, one that could safely be blocked during the suspend. But I had another thought.
I haven't paid much attention to your sysfs updates. Is it still true that calls to show/store methods are mutually exclusive with attribute unregistration? Assuming the answer is Yes, would it be possible to bypass that mutual exclusion in certain explicit cases? Here's what I have in mind:
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.
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.
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?
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/
| |