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 16:31:47 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	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>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

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

On the kernel side you really want to add two arguments from day one which
is the time in ms and the power state. We have enumerations of current
power states (plus add suspend) so this is easy to do. The governors may
not use them for a while but ACPI for example can use the latency pretty
fast. You want the information there from day one so it is captured
otherwise it ends up a right royal pain in the arse adjusting the API
later. If the numbers are in but don't always get used it'll be a lot
smoother.

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

Yes. Probably it really should be linked to a cpufreq driver thing -
cpufreq_android or whatever being the starting point but thats not a big
deal and it doesn't leak into all the apps either. This is detail however.

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

There have been some horribly bad attempts to do this, but if it works
for Android and its encapsulated in cpufreq_android.c maybe with a private
interface to a single supporting daemon then it's not creating bad user
APIs, its not peeing in anyone elses pond and the policy will all be in
the kernel and a daemon which keeps the wrong platform knowledge out of
the application space.

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