[lkml]   [2010]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Attempted summary of suspend-blockers LKML thread, take three
    On Mon, 16 Aug 2010 20:20:32 -0400
    Ted Ts'o <> 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

    > 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

     \ /
      Last update: 2010-08-17 02:59    [W:0.021 / U:10.724 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site