Re: [PATCH 05/13] PM: Add option to disable /sys/power/state interface

Brian Swetland
2009-02-09T13:31:18Z

[Pavel Machek <pavel@ucw.cz>]
> > [Arve Hj?nnev?g <arve@android.com>]
> > >
> > > Yes we need access to wakelocks from user space. We also allow third
> > > party apps to use wakelocks if they request the right permission. This
> > > could include a music player keeping the device on while playing a
> > > song, or an pop email client using an alarm to download email every
> > > hour.
> >
> > To expand on this a bit: We don't allow arbitrary apps to directly grab
> > wakelocks with the sys interface -- instead a system service in
> > userspace manages wakelock requests on behalf of apps needing them.
>
> So in fact single wakelock for userspace would be enough for you?
>
> Cool, that certainly makes user<->kernel interface easier.
>
> OTOH "gcc now has to talk to system service" requirement is quite ugly.

I think we'd still want multiple entities to hold wakelocks from
userspace -- in the Android case, the daemon that handles low level
telephony state also has its own wakelock. I was speaking more from a
permission standpoint that there may not need to be a 1:1 between
userspace entities needing to keep the system from sleeping and a
wakelock in the kernel.

Arve has a prototype of a driver interface instead of the sysfs
interface where one opens /dev/wakelock to obtain a wakelock (via fd)
which can be cleaned up automatically on app exit, etc.

I don't think you'd actually want to have plain 'ol commandline tools
like gcc and so on to be modified to be aware of wakelocks. Instead,
I'd imagine you'd setup a general "run x while keeping the system awake"
tool, or maybe modify just the shell you're using.

Brian