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, 04 Jun 2010 09:24:06 -0500
From:	James Bottomley <James.Bottomley@...e.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Brian Swetland <swetland@...gle.com>, 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>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: suspend blockers & Android integration

On Fri, 2010-06-04 at 11:59 +0200, Ingo Molnar wrote:
> * Brian Swetland <swetland@...gle.com> wrote:
> > On Fri, Jun 4, 2010 at 1:55 AM, Ingo Molnar <mingo@...e.hu> wrote:
> > > * Brian Swetland <swetland@...gle.com> wrote:
[...]
> > > 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 ^^
> 
> That's a well-known problem on lkml: the light at the end of the tunnel was 
> the other train ;-)
> 
> Anyway, i'm not pessimistic at all: _some_ sort of scheme appears to be 
> crystalising out today. Everyone seems to agree now that the main usecases are 
> indeed useful and need handling one way or another - the rest is really just 
> technological discussions how to achieve the mostly-agreed-upon end goal.

It's still not clear to me whether everyone's revolving around to using
the current suspend block API because it's orthogonal to all other
mechanisms and is therefore separate from the kernel (and can be
compiled out if you don't want it).  Or whether re-expressing what the
android drivers want (minimum idle states and suspend block) in pm_qos
terms which others can use is the way to go.  I think the latter, but
I'd like to know what other people think (because I'm not wedded to this
preference).

> The worst situation are features where one side says 'we dont need this kind 
> of functionality at all' - IMO auto/opportunistic-suspend isnt in that 
> situation, fortunately.

Great ... because deprecating the problem has been one of the persistent
memes by some people on this huge thread.

James


--
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/