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: Thu, 6 May 2010 02:51:18 +0200 From: "Rafael J. Wysocki" <rjw@...k.pl> To: Mark Brown <broonie@...nsource.wolfsonmicro.com> Cc: tytso@....edu, Matthew Garrett <mjg@...hat.com>, Alan Stern <stern@...land.harvard.edu>, Brian Swetland <swetland@...gle.com>, Kevin Hilman <khilman@...prootsystems.com>, "Arve Hj?nnev?g" <arve@...roid.com>, linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org, Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>, Paul Walmsley <paul@...an.com>, magnus.damm@...il.com, mark gross <mgross@...ux.intel.com>, Arjan van de Ven <arjan@...radead.org>, Geoff Smith <geoffx.smith@...el.com>, rebecca@...roid.com Subject: Re: [PATCH 0/8] Suspend block api (version 6) On Thursday 06 May 2010, Mark Brown wrote: > On Thu, May 06, 2010 at 01:33:59AM +0200, Rafael J. Wysocki wrote: > > > set up that way). Even without the patchset you may implement a power > > manager in user space that will suspend the system whenever it thinks it's > > idle. > > Clearly, but... > > > On Thursday 06 May 2010, Mark Brown wrote: > > > > In the primary existing application this change interoperates very poorly > > > with at least the current audio subsystem since that handles suspend by > > > ceasing all activity and powering as much as it can off, which is sensible for > > > manual only suspends but highly undesirable for opportunistic suspend in > > > phones. > > > You said that there's no fundamental difference between manual and > > opportunistic suspend. It only matters what _you_ are going to use suspend > > for. I agree that at the moment it's not suitable for aggressive power > > management in phones because of the audio problem, but that applies to > > "manual" as well as to "opportunistic" suspend. > > ...on the other hand there's exactly one existing application for this, > and that's the one that's most likely to run into problems since it's a > phone OS and aggressive power management is pretty important for phones. > > Merging a feature into mainline makes it much more something which one > would expect to play nicely with the rest of the kernel - if it's > something that isn't part of the standard kernel or userspaces it's much > less surprising that additional changes may be required to produce a > well integrated system. > > > You're saying that suspend is not suitable for one particular purpose in its > > current form, which is entirely correct, but that doesn't imply that the > > patchset is wrong. > > As I keep saying I agree that merging this is reasonable given the > additional power savings it brings in practical systems today. As I > also keep saying I do want to have some understanding about what the > story is for dealing with the problems so that people can easily use > this feature out of the box. > > Like I say, my current impression is that the best approach is for > affected subsystems or drivers to implement a custom solution - does > that match your understanding and that of the other PM maintainers? I agree that this appears to be the best approach for the time being, although I can only speak for myself. Rafael -- 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