Re: [markgross@thengar.org: [RFC] wake up notifications and suspend blocking (aka more wakelock stuff)]

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 3445 bytes --]

On Sat, 15 Oct 2011 14:45:37 -0400 (EDT) Alan Stern
<stern@rowland.harvard.edu> wrote:

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

Same answer - it doesn't really matter.
In every case, the kernel's responsibility is to make the sure the event is
visible to any watching user-space process before it releases the
wakeup_source.
What user-space does then is up to user-space.
If no-one is watching the kernel is free to drop it at any stage - as soon as
it discovers no-one is watching.
When the input layer gets an event, it iterated through a list of fds which
are open on the event source and queues it to each one.  This list might be
empty - no big deal.  It was still a wakeup_event.  If we were suspended, the
write to /sys/power/state will now complete, the suspend daemon will go back
around its loop, nothing will seem to be happening, so the system will go
back to sleep.

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

/dev/input/eventX??  the evdev driver presents key-down and key-up events
separately.

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

Yes, I agree that is more precise statement of what I was trying to say - and
precision is important here.

Thanks!

NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]