Re: suspend blockers & Android integration

[Ingo Molnar]

* Brian Swetland <swetland@xxxxxxxxxx> wrote:

> On Fri, Jun 4, 2010 at 12:57 AM, Ingo Molnar <mingo@xxxxxxx> wrote:
> > * Brian Swetland <swetland@xxxxxxxxxx> wrote:
> >>
> >> We started here because it's possibly the only api level change we have 
> >> -- almost everything else is driver or subarch type work or controversial 
> >> but entirely self-contained (like the binder, which I would be shocked to 
> >> see ever hit mainline). [...]
> >
> > So why arent those bits mainline? It's a 1000 times easier to get drivers 
> > and small improvements and non-ABI changes upstream.
> >
> > 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.

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 ;-)

> > I've been tracking android-common and android-msm for a while and i have 
> > to say that it shows a very lackluster attitude towards upstream:
> >
> > ??- The latest branches i can see are v2.6.32 based today. We are in the 
> > ?? v2.6.35 stabilization cycle and are developing v2.6.36. I.e. your 
> > upstream ?? base is about a year too old.
> 
> We have some branch naming confusion and work going on in
> experimental, but our active work right now is against 2.6.34 and
> 2.6.35-rc. [...]

That's nice!

> [...]  The tegra2 work has been very aggressively following mainline 
> (rebasing against 2.6.34rc as they were getting underway), and we've been 
> sending those patches out for review, in hopes of getting that tree off on a 
> better foot.

Ah, googling for 'tegra2' gave me the magic URI:

  git remote add android-tegra2 git://android.git.kernel.org/kernel/tegra.git

I generally roam various trees for scheduler patches when i can, seeing what 
problems people are facing and trying to prevent more painful forks from 
developing. You have these changes there currently:

 d82647e: sched: make task dump print all 15 chars of proc comm
 5e3e0f1: sched: Enable might_sleep before initializing drivers.

Please submit 5e3e0f1. We can probably do that one even simpler, by turning 
__might_sleep_init_called into the only flag that __might_sleep() checks - 
i.e. not checking system_state at all.

Also, please submit d82647e, it makes sense too.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/