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

[Uli Luckas <u.luckas@road.de>]

On Monday 09 February 2009, Arve Hjønnevåg wrote:
> On Sun, Feb 8, 2009 at 6:11 PM, Uli Luckas <u.luckas@road.de> wrote:
> > On Monday 09 February 2009, Rafael J. Wysocki wrote:
> >> On Monday 09 February 2009, Pavel Machek wrote:
> >> > If wakelocks can be locked from userspace is _not_ a detail; and if
> >> > they can we do need the names.
> >>
> >> Do we?  What about one lock per process and using process names?
> >> Or better process IDs or even thread IDs?
> >
> > I like that idea. A process should be able to hold _one_ wake lock (which
> > would be released if the process dies). If it turns out, that more then
> > on lock is convenient for a process, a library can easily agregate these
> > locks. If the last userspace wake lock is released, the library code can
> > relase the processes kernel wake lock.
> >
> >> Is there a limit on the number of wakelocks a user space process can
> >> create and if not, then why?
> >
> > Agreed as stated above. We should agree right now to switch to one lock
> > per process. Arve?
>
> This would work, but how would you implement it? I'm implementing an
> ioctl interface that will allow automatic cleanup without modifying
> the task struct.
I thought about a global ref count + a per thread flag. Now if your lock ioctl 
is first called for a specific thread it increases the global ref count and 
sets the thread's 'locked' flag. If the lock ioctl is called again for this 
thread it's a noop (with warning?). Now the first unlock ioctl decreases the 
ref count and clears the locked flag. Further unlock ioctls are noops until 
the lock is taken again. 
In another thread Rafael mentioned something about reusing freezer flags. If 
needed, he can probably give a detailed hint.
Does that sound feasible?

Uli