linux-kernel - Re: suspend blockers & Android integration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 4 Jun 2010 10:55:13 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Brian Swetland <swetland@...gle.com>
Cc:	tytso@....edu, Neil Brown <neilb@...e.de>,
	Arve Hj?nnev?g <arve@...roid.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Alan Stern <stern@...land.harvard.edu>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	James Bottomley <James.Bottomley@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: suspend blockers & Android integration

* Brian Swetland <swetland@...gle.com> wrote:

> On Fri, Jun 4, 2010 at 12:57 AM, Ingo Molnar <mingo@...e.hu> wrote:
> > * Brian Swetland <swetland@...gle.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/