On Wed, 28 Apr 2010, Arve Hjønnevåg wrote:

quoted text
> >> >  suspend blockers can be used to allow
> >> > +user-space to decide whether a keystroke received while the system is suspended
> >> > +should cause the screen to be turned back on or allow the system to go back into
> >> > +suspend.
> >>
> >> That's not right.  Handling the screen doesn't need suspend blockers:
> >> The program decides what to do and then either turns on the screen or
> >> else writes "mem" to /sys/power/state.
> 
> That does not work though. Unless every key turns the screen on you
> will have a race every time the user presses a key you want to ignore.

Of course.  You are confirming what I wrote immediately below: Suspend
blockers help resolve races.  Note that this race has nothing to do
with the _screen_ in particular -- exactly the same race occurs if you
decide to turn on the audio speaker or some other piece of hardware.

quoted text
> >>  What suspend blockers add is
> >> the ability to resolve races and satisfy multiple constraints when
> >> going into suspend -- which has nothing to do with operating the
> >> screen.
> 
> I'm not sure I agree with this. You cannot reliably turn the screen on
> from user space when the user presses a wakeup-key without suspend
> blockers.

Let's say that it has nothing to do _specifically_ with the screen.  
_Any_ action you want to take in userspace is difficult to coordinate 
with system suspends if you don't have suspend blockers.

quoted text
> >>
> >> I _think_ what you're trying to get at can be expressed this way:
> >>
> >>       Here's an example showing how a cell phone or other embedded
> >>       system can handle keystrokes (or other input events) in the
> >>       presence of suspend blockers.  Use set_irq_wake...
> 
> OK, but the last version was what you (Alan) suggested last year.

So at least my mental processes have remained consistent over the span
of a year.  Nice to know I haven't undergone a complete personality 
change...  :-)

quoted text
> >>       ...
> >>
> >>       - The user-space input-event thread returns from read.  It
> >>       carries out whatever activities are appropriate (for example,
> >>       powering up the display screen, running other programs, and so
> >>       on).  When it is finished, it calls suspend_unblock on the
> >>       process_input_events suspend_blocker and then calls select or
> >>       poll.  The system will automatically suspend again when it is
> >>       idle and no suspend blockers remain active.
> >
> > Yeah, that sounds better.  Arve, what do you think?
> >
> 
> Idle is irrelevant and needs to be removed. This new last step is also
> no longer a concrete example, but if you really think is it better I
> can change it.

Perhaps you would prefer to change this completely.  Write up a 
description of what can go wrong when suspend blockers _aren't_ used, 
and show how suspend blockers can prevent the problem from occurring.

But whatever you do, don't make it appear that suspend blockers allow
user programs to make decisions (which is what you wrote before).  They 
don't -- programs can make whatever decisions they want.  Suspend 
blockers merely help them carry out the actions they have decided upon 
in a safe manner.

And don't make it appear that suspend blockers can only be used for
solving screen-related problems.

Alan Stern

--
unsubscribe notice
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/