On Monday 09 February 2009, Rafael J. Wysocki wrote: > On Monday 09 February 2009, Pavel Machek wrote: > > On Sun 2009-02-08 15:00:38, Arve Hj?nnev?g wrote: > > > On Sun, Feb 8, 2009 at 1:40 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Sun, 8 Feb 2009, Pavel Machek wrote: > > > >> Well, it is true that wakelocks could be single atomic_t ... but > > > >> they would make them undebuggable. Ok, wakelock interface sucks. But > > > >> I believe something like that is neccessary. > > > > > > > > krefs don't have name strings for keeping track of who has been > > > > incrementing or decrementing their counters. And it's true that > > > > krefs are nearly undebuggable. But somehow we've managed to struggle > > > > along without adding names to krefs. Why should wakelocks be any > > > > different? > > > > > > It sounds like you suggesting that we add another nearly undebuggable > > > interface. > > > > > > Using only a single atomic_t would not allow us to use a wakelock a > > > switch, or to specify a timeout. You could replace the list in the > > > implementation with a single atomic_t by adding more state to each > > > wakelock, but I like my current solution better. > > > > For the record, I agree here. And... if struct wakelock contains char > > * or not is a very small detail. > > It really isn't, because it means allocating (kernel) memory for each > wakelock, to store the name. > > > 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. > And why exactly do we want _every_ user space process to be able to prevent > suspend from happening? > I don't understand your question. Which porcesses do you propose can veto suspend? Which processes can't? > Moreover, why do we want user space processes to be able to take multiple > wakelocks? What's the purpose of having more than one wakelock per > process? > > 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? Uli _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
