[Pavel Machek <pavel@xxxxxx>] > > [Arve Hj?nnev?g <arve@xxxxxxxxxxx>] > > > > > > 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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
