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. Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
