Re: [linux-pm] [PATCH 1/8] PM: Add suspend block api.

[James Kosin]

On 5/6/2010 11:10 PM, Arve Hjønnevåg wrote:
> 2010/5/6 James Kosin <james.kosin.04@xxxxxxx>:
>   
>> On 5/6/2010 10:53 PM, Arve Hjønnevåg wrote:
>>     
>>> On Thu, May 6, 2010 at 7:41 PM, James Kosin <james.kosin.04@xxxxxxx> wrote:
>>>
>>>       
>>>> On 5/5/2010 8:10 PM, Tony Lindgren wrote:
>>>>
>>>>         
>>>>> * Brian Swetland <swetland@xxxxxxxxxx> [100505 16:51]:
>>>>>
>>>>>           
>>>>>> On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
>>>>>>
>>>>>>             
>>>>>>> * Brian Swetland <swetland@xxxxxxxxxx> [100505 14:34]:
>>>>>>>
>>>>>>>               
>>>>>>>> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>>                 
>>>> <<-- snip -->>
>>>>
>>>>         
>>>>>>>>> At no point does the user program have to communicate anything to the
>>>>>>>>> modem driver, and at no point does it have to do anything out of the
>>>>>>>>> ordinary except to enable and disable a suspend blocker.
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> Exactly -- and you can use the same style of overlapping suspend
>>>>>>>> blockers with other drivers than input, if the input interface is not
>>>>>>>> suitable for the particular interaction.
>>>>>>>>
>>>>>>>>                 
>>>>>>> Would the suspend blockers still be needed somewhere in the example
>>>>>>> above?
>>>>>>>
>>>>>>>               
>>>>>> How often would we retry suspending?
>>>>>>
>>>>>>             
>>>>> Well based on some timer, the same way the screen blanks? Or five
>>>>> seconds of no audio play? So if the suspend fails, then reset whatever
>>>>> userspace suspend policy timers.
>>>>>
>>>>>
>>>>>           
>>>> Tony,
>>>> Wouldn't this be handled by the idle task, or task manager?
>>>>
>>>> When all tasks are suspended and not doing anything that should be the
>>>> first clue that a real suspend cycle could be attempted.
>>>>
>>>>
>>>>         
>>> One if the benefit we get from using suspend is that an unprivileged
>>> app that does not have access to suspend blockers cannot prevent
>>> suspend. You lose this advantage if you trigger suspend only from the
>>> idle task.
>>>
>>>
>>>       
>> If the process (privileged or unprivileged) doesn't want to suspend, why
>> not just provide an interface to allow suspend to be turned off at the
>> user level.  This could block the suspend cycle in itself, and you
>> shouldn't need fine grained off/on cycles.  If an application really
>> needs the system not to suspend then they (the user) should know the
>> consequences and power requirements for such a task.
>>
>> I didn't say it had to be only from the idle task; but, that is the most
>> logical place.  If the other threads are not idle then they really
>> require work and will most likely already have a bock on the suspend anyway.
>>
>>     
> I think you missed my point. Unprivileged processes should not be
> allowed to prevent suspend.
>
>   
Ah, you want a way for the system to suspend (and enforce the suspend)
when only unprivileged processes are the only thing running....

That would mean a lot of work defining the unprivileged (or privileged)
processes, and properly suspending (or enforcing) when needed.  Yuck. 
Sorry I commented then, this is really getting deep into what I love to
do at work.
 
--
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/