Re: Attempted summary of suspend-blockers LKML thread, take three

["Ted Ts'o" <tytso@mit.edu>]

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.

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.

					- Ted