On Sun, Feb 22, 2009 at 5:48 AM, Pavel Machek <pavel@xxxxxx> wrote: > Hi! > >> > earlysuspend is an ugly hack and wakelock is very wrong name at the >> > very least... as seen in previous discussion. Can we get that fixed? >> >> I don't have a fix for earlysuspend, but it is far less important than >> wakelocks, so I can drop it from the patch series if that is >> preferred. >> >> Regarding the name, I don't agree with your statement that wakelock is >> a very wrong name. Like I said before, you can view it as a >> reader/writer lock where the readers protect the wake state of the >> system. That said, if there is a better name that more than one person >> can agree on, I can rename the api. Here is a list of suggestions I >> have seen so far along with the api I think they dictate if the >> existing functionality is to be preserved: > > >> suspend_inhibitor: (from inhibit_suspend) >> - api: suspend_inhibitor_init, suspend_inhibitor_destroy, >> suspend_inhibit, suspend_inhibit_timeout, suspend_uninhibit >> - pros: The effect is more obvious than *_lock. >> - cons: Does not match android user space api (but less confusing than >> suspend/sleep_lock). > > I like this one, as does rafael, so :-). > > I thought you are switching to /dev based api anyway so rename should > not be a problem? There is no requirement for the kernel api to match the user-space api, it is just less confusing. The android java apis provide a wakelock interface. We cannot change this api, but the both the in kernel api and the api from the kernel to user space can be changed. I did a quick poll here. 2 people preferred suspend_inhibitor and 3 people preferred wake_lock. The people who preferred wake_lock did not like the word inhibit(or). Block(er) was suggested as an alternative. -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
