[lkml]   [2010]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/8] PM: Opportunistic suspend support.
    On Tuesday 25 May 2010, Alan Stern wrote:
    > On Tue, 25 May 2010, Rafael J. Wysocki wrote:
    > > So, basically, you'd prefer to move the entire complexity to user space.
    > No, just the complexity of the userspace suspend blockers. That was
    > one of the parts of the interface that people objected to, after all.
    > > I'm not sure if that's a big win
    > It's not a _big_ win, but it is an improvement IMO.
    > > and I'm not sure anyone is actually going to
    > > implement it (and some drivers would still have to be modified to participate
    > > in this framework).
    > Of course drivers have to be modified. The kernel-layer suspend
    > blockers aren't affected by this proposal, so they still have to be
    > implemented.
    > > So again, we have a hunch that the goal may be achieved
    > > in a different way, but at this point we'd rather need a _working_ _solution_
    > > (in the form of code one can build and actually use).
    > It's not very different from what has been submitted, and I think
    > there's little doubt that it could be built and used fairly easily.
    > All we're talking about is removing the userspace suspend-blocker API
    > and the opportunistic workqueue, replacing them with an "opportunistic"
    > entry in /sys/power/state, and setting up a userspace power manager
    > process.
    > > I don't think it's realistic to expect the Android people to go and redesign
    > > their stuff along the lines you've described, because they have a working
    > > implementation (in the kernel) that they are satisfied with.
    > The redesign would be pretty small. The kernel changes relative to
    > what they have submitted are minimal, mostly just removing a few of
    > their additions. Furthermore, we've been told that Android _already_
    > funnels all its userspace suspend-blocker work through a single
    > process. All that would be needed would be to make that process
    > initiate an opportunistic suspend whenever no userspace suspend
    > blockers were active.
    > > Now, we can reject their patches, but that's not going to cause any progress
    > > to happen, realistically. Quite on the contrary, Android will continue to use
    > > wakelocks and Android driver writers will continue to ignore the mainline
    > > and the gap between the two kernel lines will only get wider and wider over
    > > time.
    > >
    > > And what really is the drawback if we merge the patches? Quite frankly,
    > > I don't see any.
    > You don't seem to appreciate how small a change Dmitry has proposed.
    > Almost all of the suspend-blocker work would remain as in the submitted
    > patches. The only difference is that the userspace API and
    > opportunistic-suspend implementation would be simplified, by moving
    > some of the work out of the kernel.

    No, I don't really think it's going to be a small change. The problem is that
    for the Android people changing user space is very hard, so I don't think
    this realy is an option, given that they would have to implement it themselves,
    test it, validate it on multiple different hardware platforms etc. and _then_
    resubmit the feature without any guarantee that it will be merged.

    So, my opinion is that we only have a choice to either take the feature as is
    now, or reject it altogether and live with the consequeces in each case. And
    quite frankly I don't feel like I'm in position to make that decision.


     \ /
      Last update: 2010-05-25 23:45    [W:0.047 / U:17.468 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site