linux-kernel - Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

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]

Message-ID: <AANLkTikKGeGHHL6AYC7uBuT7Zihj7lozfidWQ8zRHwab@mail.gmail.com>
Date:	Fri, 28 May 2010 06:27:00 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	Igor Stoppa <igor.stoppa@...ia.com>
Cc:	ext Matthew Garrett <mjg59@...f.ucam.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"tytso@....edu" <tytso@....edu>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	"Balbi Felipe (Nokia-D/Helsinki)" <felipe.balbi@...ia.com>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Fri, May 28, 2010 at 6:32 AM, Igor Stoppa <igor.stoppa@...ia.com> wrote:
>
> What I consider plain wrong i to claim that since there are this many units
> out, some code should be merged.

I've never suggested that we should get a get-out-of-code-review-free
card or be automatically merged based on shipping volume.

Hell, I never thought we should even bother trying to merge wakelocks
upstream, because I assumed that they'd be hated for not being the
linux way (tm).  Greg KH and others have spent a bunch of time
shouting at me (or Google) that we should be doing this, and here we
are giving it a go.  At this point we've spent more engineering time
on revising this one patchset (10 revisions to address various rounds
of feedback) and discussion of it than we have on rebasing our working
kernel trees to roughly every other linux release from 2.6.16 to
2.6.32 (which became much easier after switching to git).

> A company needs to cut corners sometimes when making a product but this
> should not affect upstream code.

I will disagree that wakelocks are "cutting corners" (we certainly
have some corner cutting code in our trees, because yeah, ship is
compromise, but I don't believe wakelocks are an example).  They're a
real solution for real problems faced on real devices.  Obviously not
a solution that everyone here likes, and maybe they'll never end up in
mainline as a result, but so far I haven't seen a counter proposed
solution that seems to solve the same problem, avoid races, and be
simpler/cleaner (at least to my eyes).

>> I am quite willing to state that on both MSM and OMAP based Android
>> platforms, we've found that the suspend blocker model allows us to
>> obtain a lower average power draw than if we don't use it -- Mike Chan
>> provided some numbers earlier in another thread in the trivial device
>> idle case, the win is of course much larger in the case of several
>> poorly behaved apps being active.
>
> That's very good. But if it is done in a conceptually flawed way, some
> better solution should be considered for upstream merge.

How is it flawed?  Serious question.

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