Messages in this thread | | | Date | Mon, 16 Aug 2010 17:55:03 -0700 | From | Jesse Barnes <> | Subject | Re: Attempted summary of suspend-blockers LKML thread, take three |
| |
On Mon, 16 Aug 2010 20:20:32 -0400 Ted Ts'o <tytso@mit.edu> 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
| |