Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

Brian Swetland
2010-05-26T22:18:47Z

On Wed, May 26, 2010 at 3:14 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> This whole thing is related to the statistics part, which Arve says is
>> essential to him.  He wants to collect statistics for each suspend blocker
>> activated and deactivated so that he can tell who's causing problems by
>> blocking suspend too often.  The name also is a part of this.
>
> If he wants to collect stats about misbehaving code then presumably he
> needs reliable stats. Arbitary user set names are not reliable and
> judging by app vendor behaviour in the proprietary space with other such
> examples they will actively name their blockers in a manner specifically
> intended to hide the cause so as to 'reduce support costs'.
>
> Its a waste of memory (especially if I create a million of them with a
> long name for fun).

You are limited to one per open fd of the device, and a max name size
which could be further shrunk to something pretty small (32?) if
desired. The device node interface came about after discussions last
year and concerns that userspace could create an unbounded number of
suspend blockers.

> It's all an economic system, proprietary app vendors are in it to make
> money, some will therefore game the system and the rest will be forced to
> follow to keep their playing field fair.

Untrusted (non-system) code can't directly access the device node from
userspace in the Android world -- so directly created suspend blockers
from userspace are only created by a couple system processes (3-4
typically). Applications are sandboxed by UID and there is (much
more) per-application accounting in the userspace application manager
process (other resource consumption such as sensors, CPU, etc is
tracked here as well).

For suspend blockers created by drivers and by trusted userspace
processes, having a meaningful name significantly helps statistics
gathering.

Brian