On Sun, 20 Jun 2010, mark gross wrote: > > Indeed, the same problem arises if the event isn't delivered to > > userspace until after userspace is frozen. Of course, the underlying > > issue here is that the kernel has no direct way to know when userspace > > has finished processing an event. Userspace would have to tell it, > > which generally would mean rewriting some large number of user > > programs. > > Suspend blockers don't solve this, and the large number of user programs > isn't a big number. /me thinks its 1 or 2 services. On Android, perhaps. What about on other systems? > > In what way is this better than suspend blockers? > > 1) I don't think suspend blockers really solve or effectively articulate > the suspend wake event race problem. Why not? > 2) the partial solution suspend blocker offer for the suspend race is > tightly bound to the suspend blocker implementation and not useful in > more general contexts. I don't understand. Can you explain further? > > One advantage of the suspend-blocker approach is that it essentially > > uses a single tool to handle both kinds of races (event not fully > > handled by the kernel, or event not fully handled by userspace). > > Things aren't quite this simple, because of the need for a special API > > to implement userspace suspend blockers, but this does avoid the need > > for a power-manager process. > > I don't think suspend-blocker handles both kinds of races as well as you > seem to think. Can you give any counterexamples? > A single tool that conflates multiple kernel facilities > is not an advantage. It limits applications outside of the scope of > doing it the "android way". I don't see that necessarily as a drawback. You might just as well say that the entire Linux kernel limits applications to doing things the "Unix" way. Often have fewer choices is an advantage. > Where do you get the idea that there isn't a need for a centralized PM > process in Android? Thats not true. I didn't get that idea from anywhere. Sorry if I gave the wrong impression -- I meant that non-Android systems would need to implement a centralized power-manager process, along with all the necessary changes to other programs. (Incidentally, even on Android the centralized PM process does not handle _all_ of the userspace/kernel wakelock interactions.) Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
