Messages in this thread | | | Date | Mon, 16 Jul 2012 15:04:27 -0700 | Subject | Re: [PATCH] epoll: Add a flag, EPOLLWAKEUP, to prevent suspend while epoll events are ready | From | Arve Hjønnevåg <> |
| |
On Mon, Jul 16, 2012 at 4:00 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Monday, July 16, 2012, Michael Kerrisk wrote: >> Arve, Rafael, >> >> On Tue, May 1, 2012 at 7:33 AM, Arve Hjønnevåg <arve@android.com> wrote: >> > When an epoll_event, that has the EPOLLWAKEUP flag set, is ready, a >> > wakeup_source will be active to prevent suspend. This can be used to >> > handle wakeup events from a driver that support poll, e.g. input, if >> > that driver wakes up the waitqueue passed to epoll before allowing >> > suspend. >> >> It's late it the -rc series, > > Well, exactly. :-) > >> but it strikes me that CAP_EPOLLWAKEUP is >> a poor name for the capability that governs the use of EPOLLWAKEUP. >> While on the one hand some capabilities are overloaded >> (https://lwn.net/Articles/486306/), on the other hand we should avoid >> adding individual capabilities for each new API feature (otherwise >> capabilities become administratively unwieldy). >> >> This capability is not really about "EPOLL". It's about the ability to >> block system suspend. Therefore, IMO, a better name would be something >> like: CAP_BLOCK_SUSPEND. This name is better because there might be >> some other API feature that is later added that also has the effect of >> preventing system suspends, and we could reasonably govern that >> feature with the same capability.
We already have another api, "/sys/power/wake_lock", that allow user-space to block suspend. Do we want to apply this capability that api as well, or only to apis that do not have other ways to restrict access?
>> >> Does that seem sensible to you? I can send a patch for the name change. > > I'm not sure what Arve thinks about that, but I'd be fine with that. > > Arve, what do you think? >
CAP_BLOCK_SUSPEND is fine with me, but if it does not apply to the sysfs interface, then the comment should probably mention this.
-- Arve Hjønnevåg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |