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]

Date:	Thu, 27 May 2010 11:06:23 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Thomas Gleixner <tglx@...utronix.de>
cc:	Arve Hjønnevåg <arve@...roid.com>,
	Peter Zijlstra <peterz@...radead.org>,
	<Paul@...p1.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.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)

If people don't mind, here is a greatly simplified summary of the 
comments and objections I have seen so far on this thread:

	The in-kernel suspend blocker implementation is okay, even
	beneficial.

	Opportunistic suspends are okay.

	The proposed userspace API is too Android-specific.

	More kernel mechanisms are needed for expressing processes'
	latency requirements.

The last one is obviously a longer-term issue, so let's ignore it for
now.  That leaves as the only point of contention the userspace
suspend-blocker API.

The proposal I made a couple of days ago removes this API and leaves
the other things (i.e., the in-kernel suspend blockers and
opportunistic suspend) intact.  In place of the userspace
kernel-blocker API, Android would have to implement a power manager
process that would essentially juggle all the latency requirements in
userspace.

Communication between the power manager process and the kernel would be 
limited to adding a new "opportunistic" entry to /sys/power/state -- 
something which could well be useful in its own right.  Even if this 
API turns out not to be good, it's simple enough that it could be 
removed pretty easily.

This answers Alan Cox's (and other's) desire not to implement a 
questionable or special-purpose API.  And it also answers Thomas's 
desire to make scheduling decisions based on latency requirements 
(although the answer is simply to punt all these decisions out of the 
kernel and into userspace -- which is reasonable for now since the 
alternative would require a long-term kernel development effort).

Indeed, having a power manager thread may well turn out to be a useful
thing -- but even if it doesn't, this scheme minimizes the damage while
still allowing the Android platform to use a vanilla kernel with only
limited modifications to their userspace.

Alan Stern

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