On Tue, 2010-05-25 at 15:33 -0700, Arve Hjønnevåg wrote: > The biggest problem here is not that it is hard to change our > user-space, but that the proposed change is inferior to what we have > now. It forces us to poll until all drivers stop aborting suspend. On > one hand we have people telling us that all code that polls is broken > and must be fixed (instead of suspending to limit the damage), and on > the other hand we have people suggesting we implement opportunistic > suspend by polling from user-space until suspend succeeds. No it does _not_. You're really not getting that Dmitry is proposing. So your proposal is that when we wake userspace, it opens /dev/suspend_blocker _before_ it consumes whatever event, consumes the event, deals with the event, then closes the suspend_blocker. Then the kernel, upon reaching a 0 suspend_blocker count, will try to suspend again. What Dmitry proposes is that, the app _before_ it consumes the event, pokes at this suspend manager, it increases a blocker count, then consumes the event (the kernel will _not_ auto-suspend), handles it and then again pokes the suspend manager, this time decreasing the blocker count. The suspend manager will, upon reaching a 0 block count, suspend the machine. If that fails, it means there's something to do, an app will inc, work, dec its count, and it will try again once it reaches 0 again. There is no polling what-so-ever in this model. The only thing is that the kernel will not try to auto-suspend and there is no user-space suspend blocker API. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
