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
| ||
|
Date: Fri, 28 May 2010 20:10:38 -0700 From: mark gross <640e9920@...il.com> To: Alan Stern <stern@...land.harvard.edu> Cc: Thomas Gleixner <tglx@...utronix.de>, 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) On Thu, May 27, 2010 at 11:06:23AM -0400, Alan Stern wrote: > 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. Only if they only block. You get into trouble when the in kernel un-block opperation triggers an implicit suspend. > > Opportunistic suspends are okay. > > The proposed userspace API is too Android-specific. > > More kernel mechanisms are needed for expressing processes' > latency requirements. True. --mgross > > 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 > > _______________________________________________ > linux-pm mailing list > linux-pm@...ts.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/linux-pm -- 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/
Powered by blists - more mailing lists