> of PSARC/2008/021 HAL Power Management Support. Also, I hope this
> document would be sufficent to move these power management cases
> forward.
That depends on the scope of the umbrella requested. This
seems limited to the interaction between HAL PM support
and the LSARC GPM case.
> Please review.
Below. Thanks for the additional information. As this may
be a part of a continuing spec, I'll note some nits as well
as questions still unresolved.
> Administration
> Any changes that a user makes to the GPM graphical user interface preferences
> are stored in the GConf database and persists across reboots.
Nit. I believe the intent here is to persist across login
sessions, not just reboots.
> GPM Defaults
> For any user who is logged into an X session, GPM will by default
> have these actions:
How does this user get permission to do these actions?
What happens if the user doesn't have permission?
> If no one is logged into an X session, the defaults above will be true
> except for the following:
In some sense, how/when is this done? Upon initial system boot
and at every logout? Is there a notification architecture for
user logout?
> Lid - When a user closes the lid, the system will by default suspend if
> supported. If suspend is not supported, the action will be to do nothing
> by default. One can change the default to do nothing.
Who is the "One"? How does the "One" change things?
Are these system wide defaults? Are there new /etc files?
Are the defaults part of an SMF service? What service? ...
> Auditing
> in accordance to the Solaris Auditing Policy. However, any issues
> with auditing in the current power management interfaces will be
> considered a bug.
I agree with it being an audit bug and have filed
6664265 uadmin(1M) auditing seems a mess
What I was asking the team about was the architecture that was
relevant to audit across a system discontinutity. It's neither
self evident from this case, or uadmin(1M), or uadmin(2).
I've also filed a man page bug 6664263 uadmin(2) is incomplete
Reading over 1992/201, 1992/202, 1993/243, 1993/319, 1993/462,
1996/058, 1996/257, 1997/126, 1997/326, 2005/067 haven't filled
in the gaps.
Is there a suggestion where else to gleen the architecture?
> Security
> PolicyKit is a security policy on Linux similar to RBAC. The plan has
> been to port the pieces that are needed into RBAC. libpolkit is a
> small piece of PolicyKit that has been ported to use RBAC since its
> introduction in PSARC/2005/399 Tamarack: Removable Media Enhancements. So
> far, projects will only port the piece of PolicyKit that is needed. What
> about the rest of PolicyKit? Any piece of PolicyKit used by a project team
> would be required to port to RBAC and thus keep with the requirement
> of having only one security policy and administration.
I remain concerned with a piece meal approach without an umbrella
to describe how/where the pieces fit together.
Gary..
