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: Sun, 1 Aug 2010 18:16:57 -0400 (EDT) From: Alan Stern <stern@...land.harvard.edu> To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> cc: 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>, <swetland@...gle.com>, <peterz@...radead.org>, <tglx@...utronix.de>, <alan@...rguk.ukuu.org.uk> Subject: Re: Attempted summary of suspend-blockers LKML thread On Sun, 1 Aug 2010, Paul E. McKenney wrote: > > I should have made a stronger point: "power-aware" is _not_ a good > > term for these applications. "power-enabled" would be better but > > still not ideal. Maybe "power-permitted"? The definition is that > > they are _permitted_ to do something (acquire suspend blockers), not > > that they actually _do_ something. > > How about "PM-driving applications", as Rafael suggested? Perhaps. But it's a little misleading, since what these applications are permitted to do is to _prevent_ the system from going to low power. So in a real sense they don't drive PM -- they block it. (Indeed, that's what inspired the name "suspend blocker".) Of course, the same objection applies to "power-permitted". > > I was agreeing with the requirement but disagreeing with the reason > > given for it. Even when buffers are large enough that the danger of > > overrunning them is infinitesimal, delays in input event delivery are > > still undesirable. > > > > Besides, the Android kernel doesn't vary its behavior based on whether > > the recipient is power-permitted or power-naive; it _always_ delivers > > input events in a timely fashion. > > True, the difference between the two classes of applications is in > whether or not the application is permitted to process the event. > > I added "and to minimize response latencies" to the requirement. > Does that capture it? Yes. > > > But leaving that aside, I thought that Arve and Brian explicitly > > > stated this as a requirement on power-aware applications -- one of the > > > responsibilities that came with the power to block suspend. > > > > No. There are _no_ requirements on power-permitted (or power-aware if > > you prefer) applications, other than that the user decides to give it > > the appropriate permission. > > > > Internally, of course, Android may enforce this rule on their own > > software. But it has no force in regard to external applications. > > So should this be moved to a new "ANDROID POLICY" section or some such? Or DESIRED BEHAVIOR, or some such. 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/
Powered by blists - more mailing lists