On Mon, 3 May 2010, mark gross wrote: > You know things would be so much easier if the policy was a one-shot > styled thing. i.e. when enabled it does what it does, but upon resume > the policy must be re-enabled by user mode to get the opportunistic > behavior. That way we don't need to grab the suspend blocker from the > wake up irq handler all the way up to user mode as the example below > calls out. I suppose doing this would put a burden on the user mode code > to keep track of if it has no pending blockers registered after a wake > up from the suspend. but that seems nicer to me than sprinkling > overlapping blocker critical sections from the mettle up to user mode. > > Please consider making the policy a one shot API that needs to be > re-enabled after resume by user mode. That would remove my issue with > the design. This won't work right if a second IRQ arrives while the first is being processed. Suppose the kernel driver for the second IRQ doesn't activate a suspend blocker, and suppose all the userspace handlers for the first IRQ end (and the opportunistic policy is re-enabled) before the userspace handler for the second IRQ can start. Then the system will go back to sleep before userspace can handle the second IRQ. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
