> > > No, we are talking of allocating kernel memory on behalf of user space > > > processes with no apparent limitations. > > > > Ok, I see now. Yes, letting each process allocated unlimited number of > > wakelocks is indeed bad. > > > > (But the names for in-kernel users should be ok, right?) > > Yes, in principle, but what exactly the benefit would be? > > In the kernel we can use rwlock for blocking suspend, for example, > that will be taken for reading by the code paths wanting to prevent suspend > from happening and for writing by the suspend code. > > > "Wakelock is a filedescriptor" would solve that... > > Sort of. > > Still, I don't think there's much point in having more than one "wakelock" > per process. > > Moreover, I _guess_ it would be sufficient to have only one such thing for > the entire user space and single daemon and a (user land) library to manage it. ...which is what android userland actually does... OTOH they also veto suspend if any events are unprocessed on input device queues... so tying it to filedescriptor would make some sense. -- (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
