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

[David Chieu]

Gary Winiger wrote:
>>>>>     Not really.  When the kernel resumes, I would presume it stats
>>>>>     at the next kernel instruction following the instruction that
>>>>>     caused it to go into suspended animation.  I would presume it
>>>>>     does not run genuinx:main() again that starts the system fresh
>>>>>     in a reboot, so I ask how is the resumed from suspended animation
>>>>>     audited?
>>>>>
>>>>>           
>>>> I agree that any process resumed should start at the next instruction.
>>>>
>>>> As for the auditing of resume, I don't know how exactly it was done.
>>>> I'll have to look up the bug and code that was integrated for this
>>>> auditing.
>>>>         
>>> The auditing of suspend is handled by the uadmin.c code.  It creates an
>>> audit record and the ends the auditing session before the actual
>>> suspend.
>>>
>>> Phi
>>>       
>>   From what I remember, the team has agreed to do auditing either by
>> direct code, or via commands that are known to audit (i.e. halt(1M),
>> reboot(1M), uadmin(1M)).  Failure to do it properly in HAL is a bug.
>> Failure to do it properly in existing tools is a bug.
>>     
>
> 	The architectural point is how does the project team expect to
> 	meet the requirements?  I don't believe existing interfaces 
> 	implementations are sufficient.  IMO this is not, the (non-existant)
> 	Audit project team will do it for us.  This actually requires some
> 	architecture on resuming after suspended animation that I was
> 	guessing the project team hadn't yet considered or addressed.
>
> Gary..
>   
The project team understands your concern and wishes to work with you 
privately since there are many unresolved issues still. We've already 
marked this case "waiting need spec" with no foreseeable timeout. Your 
concerns will be communicated and duly written with satisfactory answers 
of your standard in the case spec.txt.

-- David Chieu