lkml.org 
[lkml]   [2011]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [: [RFC] wake up notifications and suspend blocking (aka more wakelock stuff)]
On Sat, 15 Oct 2011, NeilBrown wrote:

> On Thu, 13 Oct 2011 11:16:23 -0400 (EDT) Alan Stern
> <stern@rowland.harvard.edu> wrote:
>
> > On Thu, 13 Oct 2011, NeilBrown wrote:
> >
> > > Nope, but I'm keen for you to convince me. Identify a wakeup event that
> > > cannot be made visible to poll (or to user-space by some other
> > > mechanism) before the wakeup_source needs to be deactivated. Or if I've
> > > misunderstood what sort of notification is problematic, help me understand.
> >
> > Here's an example (just for kicks, not completely relevant to your
> > discussion): A USB keyboard key release. Unlike key presses, key
> > releases need not generate input events. If no processes are
> > monitoring the raw keyboard event queue then the release is not visible
> > to userspace at all, hence not visible before the wakeup_source needs
> > to be deactivated.
> >
> > Alan Stern
>
> As you say, not completely relevant.
>
> If a tree falls in a forest with no one to here, does it make a sound?
>
> similarly if an event happens that no-one is looking for, is it visible?
> It doesn't really matter.

That's a different question, but I'll answer it anyway: Yes, it does
matter. If the kernel is unable to _know_ that nobody is looking for
an event, it has to _assume_ that somebody is. Then what should happen
if it turns out that nobody really is looking for it?

> So at most this is a case of "is not made visible" rather than "cannot be
> made visible".

In this case it's the same thing. How can a key release be made
visible?

> The key-release just needs to clear the "key is pressed" state so that
> auto-repeat stops and if it was a modifier, the modification is discarded.
> That is all trivially done in some kernel driver while the wakeup_source is
> active.

In other words, if the event is discarded from within the kernel then
the wakeup_source can be deactivated at that time. That's fine -- but
it indicates that your original request above was phrased wrongly. You
should have asked for an example of a wakeup_source which the kernel
must not deactivate without a userspace handshake, but which cannot be
made visible by poll or some other similar mechanism.

Alan Stern



\
 
 \ /
  Last update: 2011-10-15 20:47    [W:0.079 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site