lkml.org 
[lkml]   [2012]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    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 <arve@android.com> wrote:
    > 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. :-)

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

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

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

    Thanks,

    Michael

    --
    Michael Kerrisk Linux man-pages maintainer;
    http://www.kernel.org/doc/man-pages/
    Author of "The Linux Programming Interface", http://blog.man7.org/
    --
    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/

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