On Mon, 16 Aug 2010 20:20:32 -0400 Ted Ts'o <tytso@xxxxxxx> wrote: > On Mon, Aug 16, 2010 at 08:16:55AM -0700, Jesse Barnes wrote: > > Fortunately in this case the problem doesn't seem to be fatal. We've > > already established that the userland API portion of suspend blockers > > could be implemented in userspace with a bit more work, given that the > > kernel problems with suspend/resume and events are addressed. > > Hopefully Google is already developing a prototype userspace > > implementation to make sure it's workable; being able to build stock > > upstream kernels for my Droid and its Android userspace sure would be > > nice. > > You know, you don't have to wait for the Android engineers to do this > work. You (or others who want to be able to use stock upstream kernel > with Android devices) could just as easily try to do the "bit more > work" yourselves --- that is, do the open souce thing and scratch > one's own itch. Sure, I could. And the Google guys could put together a whole Debian distro with suspend blockers sprinkled throughout various apps. But for my part, I can't justify that kind of work at the moment. Of course I'd be happy if someone could and did do the work, it would be a useful exercise and potentially allow Android to work well on stock kernels. > After all, Rafael is saying he's refusing to accept patches (or > implement) in-kernel oppunsitic suspend for upstream unless it's > proven to him that a userspace implementation isn't sufficient. It > might be just as fair for the Android userspace upstream to refuse to > accept (or engineer) userspace changes unless it is proven that the > userspace version of opporunistic suspend is just as good as the > in-kernel version which is successfully been deployed in millions and > millions of shipping units today... > > Speaking personally, it's not clear to me how waking up a userspace > suspend daemon and waiting for it to get scheduled will result in > better power savings than simply handling it in the kernel, but as > soon as someone is willing to do the work, we can find out for sure > who is right. Yeah it would add some overhead, since suspend blocker calls would use IPC to a userspace daemon, which would also be responsible for (periodically?) waking up to see if the system ought to be suspended... I agree coding it up would be a useful exercise. -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
