On Monday 09 February 2009, Pavel Machek 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 it can be #ifdef DEBUG or something, I don't see a problem. And it > does not need to allocate anything, most wakelocks will be just > static. So we are talking about 10bytes per wakelock of overhead -- > not too bad. No, we are talking of allocating kernel memory on behalf of user space processes with no apparent limitations. Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
