Re: suspend blockers & Android integration

On Fri, Jun 4, 2010 at 1:55 AM, Ingo Molnar [off-list ref] wrote:

* Brian Swetland [off-list ref] wrote:

quoted

quoted

After basically two years of growing your fork (and some attempts to get
your drivers into drivers/staging/ - from where they have meanwhile
dropped out again) you re-started with the worst possible thing to merge:
a big and difficult kernel feature affecting many subsystems. Why?

Because a large number of our drivers depend on it.

So why not put in some stub or so? Auto-suspend/suspend-blockers is a feature,
and drivers ought to be able to work without a feature as well. Keep the
suspend-blocker changes in the android tree initially, and get the main body
of changes out first, and establish a flow of timely changes. That reduces
your maintenance burden and increases trust for future changes - a win-win
situation.

The impression I got from previous discussions was that upstream did
not want things that were built conditionally around APIs that did not
exist in mainline nor stub implementations for things that were not
agreed upon.

We could easily either #if defined(CONFIG_SUSPEND_BLOCKERS) or submit
a suspend_blockers.h that just makes everything a no-op, if that's an
acceptable transition vehicle.  I didn't think either were an option
open to us.

In any case, this is not to suggest that the suspend-blocker bits are
'impossible' to merge. I just say that if you start with your most difficult
feature you should not be surprised to be on the receiving end of a 1000+
mails flamewar on lkml ;-)

Yeah, I do understand that we're not making it easy for ourselves
here.  I think we hit the point where Rafael and Matthew signed off on
things and thought "aha, linux-pm maintainers are happy, now we're
getting somewhere" only to realize the light at the end of the tunnel
was a bit further out than we anticipated ^^

Brian