> [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. Well, changing all the applications is ugly. Teaching user to use "awake make" is even more so. Shell modification.. first there are many shells, second what if command user ran just sits there? Like another shell? ...so I don't see how that would work. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
