[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMP5XgfF3RF1hSonS_QrC8jQZyCcNfwGYZcCxnew02Rp3-CXKA@mail.gmail.com>
Date: Mon, 16 Jul 2012 15:04:27 -0700
From: Arve Hjønnevåg <arve@...roid.com>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: Michael Kerrisk <mtk.manpages@...il.com>,
NeilBrown <neilb@...e.de>,
Linux PM list <linux-pm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Magnus Damm <magnus.damm@...il.com>, markgross@...gnar.org,
Matthew Garrett <mjg@...hat.com>,
Greg KH <gregkh@...uxfoundation.org>,
John Stultz <john.stultz@...aro.org>,
Brian Swetland <swetland@...gle.com>,
Alan Stern <stern@...land.harvard.edu>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>, mtk@....net
Subject: Re: [PATCH] epoll: Add a flag, EPOLLWAKEUP, to prevent suspend while
epoll events are ready
On Mon, Jul 16, 2012 at 4:00 AM, Rafael J. Wysocki <rjw@...k.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@...roid.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists