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: <alpine.LFD.2.00.1006052318050.2933@localhost.localdomain>
Date:	Sat, 5 Jun 2010 23:24:40 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Florian Mickler <florian@...kler.org>
cc:	Felipe Contreras <felipe.contreras@...il.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Paul@...p1.linux-foundation.org,
	LKML <linux-kernel@...r.kernel.org>, felipe.balbi@...ia.com,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Sat, 5 Jun 2010, Florian Mickler wrote:
> On Sat, 5 Jun 2010 23:26:27 +0300
> Felipe Contreras <felipe.contreras@...il.com> wrote:
> 
> > Supposing there's a perfect usage of suspend blockers from user-space
> > on current x86 platforms (in theory Android would have that), is the
> > benefit that big to consider this a strong argument in favor of
> > suspend blockers? Considering the small amount of x86 platforms using
> > Android (is there any?), the fact that nobody else will use suspend
> > blockers, and that x86 is already being fixed (as mentioned many times
> > before) so dynamic PM is possible, I don't think we should be
> > considering current x86 at all for suspend blockers.
> 
> A solution for the desktop to deprecate having to shut down the
> machine would not be that bad, wouldn;t it? (Why have I to shut down
> my machine anyway?) 
> 
> In my opinion such a decision (when to shutdown) has to be guided by
> userspace knowledge.
> Future x86 hardware is to be fixed (as I read in this discussion), so
> using suspend blockers could be the tool of choice. 
> 
> But alright. Let's be a little bit more focused on the present
> situation:
> 
> 1) There currently is no other solution.

Wrong. The solutions are there, just being refused.

> 2) It is a first stepping stone to bringing android to mainline.

Crap. Once we have an userspace API we are bound to it. Period. 

Also there is no technical reason why the whole driver stack cannot
be merged w/o the suspend blockers.

> 3) Any "perfect" solution will emerge anyway. As there are so many
> people with so strong opinions engaged in this discussion, I'm
> confident.

Yes, and that needs cooperation and compromises from both sides and
not just blindly defining that there is no other solution.

> 4) If there is a better solution, android will shurely adapt it as
> soon as it is there. 

Sure, after we accepted the crap there is no incentive at all.

Stop that advertising campaing already.

No thanks,

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