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? And why exactly do we want _every_ user space process to be able to prevent suspend from happening? 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? Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
