[lkml]   [2012]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] epoll: Add a flag, EPOLLWAKEUP, to prevent suspend while epoll events are ready
    On Tue, Jul 17, 2012 at 12:04 AM, Arve Hjønnevåg <> wrote:
    > On Mon, Jul 16, 2012 at 4:00 AM, Rafael J. Wysocki <> wrote:
    >> On Monday, July 16, 2012, Michael Kerrisk wrote:
    >>> Arve, Rafael,
    >>> On Tue, May 1, 2012 at 7:33 AM, Arve Hjønnevåg <> 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. :-)

    If someone had CCed linux-api@ along the way (as per
    Documentation/SubmitChecklist), it might have helped ;-)

    >>> 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
    >>> (, 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?

    Well, the question is: is there a governor on the use of
    /sys/power/wake_lock? It makes sense either they are both governed
    (preferably by the same mechanism, I would have thought), or neither

    >>> 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.

    I've sent a patch, but omitted mention of API details in the comments.
    Maybe that can be changed afterward, when a decision has been reached
    about governing /sys/power/wake_lock.



    Michael Kerrisk Linux man-pages maintainer;
    Author of "The Linux Programming Interface",
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2012-07-17 08:02    [W:0.030 / U:0.216 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site