From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933420Ab0D3SGf (ORCPT ); Fri, 30 Apr 2010 14:06:35 -0400 Received: from mail-pw0-f46.google.com ([209.85.160.46]:57265 "EHLO mail-pw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757891Ab0D3SGU convert rfc822-to-8bit (ORCPT ); Fri, 30 Apr 2010 14:06:20 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Thu, 29 Apr 2010 16:39:29 -0700 Message-ID: Subject: Re: [PATCH 1/8] PM: Add suspend block api. From: =?ISO-8859-1?Q?Arve_Hj=F8nnev=E5g?= To: Alan Stern Cc: "Rafael J. Wysocki" , Linux-pm mailing list , Kernel development list , Tejun Heo , Oleg Nesterov , Len Brown , Pavel Machek , Randy Dunlap , Jesse Barnes , Nigel Cunningham , Cornelia Huck , Ming Lei , Wu Fengguang , Andrew Morton , Maxim Levitsky , linux-doc@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2010/4/29 Alan Stern : > 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 >> 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. > >> >> >> >> 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 the kernel/drivers. > > And don't make it appear that suspend blockers can only be used for > solving screen-related problems. How about: - 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 process_input_events suspend_blocker. -- Arve Hjønnevåg