Re: [PATCH 1/8] PM: Add suspend block api.
From: Arve Hjønnevåg
Date: Fri Apr 30 2010 - 14:06:41 EST
2010/4/29 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> On Wed, 28 Apr 2010, Arve Hjønnevåg wrote:
>> >> > 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
Yet you offered it as an example of why "Handling the screen doesn't
need suspend blockers".
> 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.
I agree with this, but that does not mean that describing how you can
handle the screen with suspend blockers is a bad example.
>> >> 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
> 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.
>> >> 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... :-)
>> >> ...
>> >> - 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.
I think suspend blockers do allow user programs to make decisions.
Without suspend blockers some decisions can only be safely be made in
> And don't make it appear that suspend blockers can only be used for
> solving screen-related problems.
- The user-space input-event thread returns from read. If it
determines that the key should be ignored, it calls suspend_unblock on
the process_input_events suspend_blocker and then calls select or
poll. The system will automatically suspend again, since now no
suspend blockers are active.
If the key that was pressed instead should preform a simple action
(for example, adjusting the volume), this action can be performed
right before calling suspend_unblock on the process_input_events
suspend_blocker. However, if the key triggers a longer-running action,
that action needs its own suspend_blocker and suspend_block must be
called on that suspend blocker before calling suspend_unblock on the
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/