GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008]

[Bart Blanquart]

On 18 Jan 2008, at 11:38, Darren J Moffat wrote:

> Randy Fishel wrote:
>> On Thu, 17 Jan 2008, Darren J Moffat wrote:
>>> I like your rationale for why there are multiple authorisations.   
>>> I'd
>>> recommend though that it be three not two, ie:
>>>
>>> 	solaris.system.power.suspend.disk
>>> 	solaris.system.power.suspend.ram
>>   We came to the proposed choice after a fair bit of discsussion  
>> around how many authorizations were "required", and it is trivial  
>> to add (now or later) the 'disk' auth.  Is this a common  
>> recommendation, especially considering the 'hierarchical' nature  
>> of the actual command (disk implies ram)?
>
> Isn't it an implementation issue though that suspend to disk first  
> does a suspend to ram ?
> I think the symmetry is worth while here.

In practice I believe most people that get any of these  
authorisations will be given "solaris.system.power.suspend.*", though  
some sites may choose a more fine-grained authorisation assignment.  
Most of the customers that I've dealt with that are interested in  
finer grained controls would grant either  
"solaris.system.power.suspend.*" or  
"solaris.system.power.suspend.ram", but I can see some cases where  
granting "solaris.system.power.suspend.disk" but not  
"solaris.system.power.suspend.ram" makes sense (say, avoiding data  
loss in areas of rolling black outs by avoiding even accidental  
suspend to ram).

I would expect that if a user has solaris.system.power.suspend.disk  
(but not solaris.system.power.suspend.ram) that that user will be  
able to suspend to disk only -- i.e. once the user OKs the  
'hibernate' dialog the system will not stop after suspending to ram,  
it will write out the image to disk. The fact that it goes through  
the motions of a suspend to ram initially are, as Darren says, just  
an implementation detail.

Bart