linux-kernel - Re: Attempted summary of suspend-blockers LKML thread, take three

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.DEB.2.00.1008062010510.30564@asgard.lang.hm>
Date:	Fri, 6 Aug 2010 20:14:09 -0700 (PDT)
From:	david@...g.hm
To:	Brian Swetland <swetland@...gle.com>
cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	arve@...roid.com, mjg59@...f.ucam.org, pavel@....cz,
	florian@...kler.org, rjw@...k.pl, stern@...land.harvard.edu,
	peterz@...radead.org, tglx@...utronix.de, alan@...rguk.ukuu.org.uk,
	menage@...gle.com, david-b@...bell.net, James.Bottomley@...e.de,
	tytso@....edu, arjan@...radead.org, swmike@....pp.se,
	galibert@...ox.com, dipankar@...ibm.com
Subject: Re: Attempted summary of suspend-blockers LKML thread, take three

On Fri, 6 Aug 2010, Brian Swetland wrote:

> On Fri, Aug 6, 2010 at 4:59 PM,  <david@...g.hm> wrote:
>>
>> now, android is betting that the apps are all developed specifically for the
>> android from scratch, so having a different API is acceptable, even if it
>> cuts them off from the rest of the *nix applications. For a phone this is
>> not neccessarily an unreasonable stance, but as Android moves into the
>> spaces where normal applications are in use (netbooks and tablets), this
>> becomes a much shakier stance to take.
>
> "Normal" apps work reasonably well -- they get halted when the screen
> turns off, just like they do when my laptop suspends.
>
> Wakelocks are useful for mobile-centric apps that you want to keep
> running in the background, wake up and do work when the device is
> "asleep", etc.

that description sounds far more like normal sleep power management that 
suspending. especially since they want to set timers to wake the system up 
and the defining characteristic of suspend (according to this thread) is 
that timers don't fire while suspended.

as I am seeing it, there are two reasons why this don't "just work"

1. sleeping can't currently save as much power as suspending

2. the current logic for deciding to sleep can't ignore the other apps on 
the system.

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