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

[NeilBrown]

On Sun, 23 Oct 2011 18:18:04 -0700 mark gross <markgross@xxxxxxxxxxx> wrote:

> Sorry for going AWOL on this thread.  I had some biz travel and fires to
> fight.

:-)  Life happens.  Welcome back.


> > So it is a good example and highlights the difficulty of defining exactly
> > what a wake-up event it, and of what it means to be "visible".
> > 
> > I think it still fits in your rephrasing of my question which - if I rephrase
> > it as a requirement - is roughly,
> > 
> >   A wakeup-event that needs to be handled by user-space must be visible to
> >   user-space before the driver deactivates the wakeup_source.
> > 
> > A requirement which, in this case, means the driver needs to hold  the
> > wakeup_source for an extended time using a timeout, just as you say.
> 
> Timeout?  why can't we define a proper notification handshake for such
> things?  Timeouts are never right IMO.
> 

I thought that before, but I have come around to the opposite way of thinking
thanks to some instructive examples from Alan and Rafael.

Some things are simply not visible to the OS.  We can expect them to be
happening but we cannot be sure and there is no clear signal that they aren't
actually happening.  So we need a timeout.

- OS cannot detect state of user's brain, so uses a time-out to blank the
  screen after a period of inactivity.
- USB cannot (I think) know which USB device triggered a wake-from-suspend,
  and in any case cannot directly ask the device why it woke from suspend.
  It has to wait for the device to tell it (in response to a regular
  'interrupt' poll I assume - but it isn't guaranteed to be reported on the
  first poll) - or timeout and give up waiting.
- A wake-on-Lan packet may wake a suspend up, but not be further visible to
  the OS.  And even if it was, the 'SYN' packet or maybe 'ARP' packet that
  might be expected to follow it is invisible until it actually arrives, and
  it may not ever come.  So we need a timeout to give up waiting after a
  while.

When-ever we are dealing with external events we need timeouts - and
wake-from-suspend is primarily about external events.

So *somewhere* in the handling of wakeup events there must be timeouts.
Whether that should be explicit in the wakeup-source is possibly a separate
question.  Maybe you could argue that the low level device driver must have
timeouts anyway, so it should use them to explicitly deactivate the source
rather than the source having it's own timeout.
I'm not sure that argument would work though it might.
But saying "Timeouts are never right" cannot work - unless you mean it in a
much more restricted sense than I think you mean it.

(I can agree that it is *best* if timeouts never fire - if direct action
causes the wakeup-source to deactivate long before the timeout.  I agree that
is the best case and probably should be the common case, but I cannot see how
it can be the only case).

Thanks,
NeilBrown

Attachment: signature.asc
Description: PGP signature