Randy and I discussed more about persistence wrt the following
proposed API:
pm_is_suspend_enabled(mode, session)
Enabled because of power.conf setting "S3-support" to enabled or it
is a machine on the White List
Session could be either "static" or "dynamic". There might
be other types of values for session in the future.
If reading if s/r is enabled from statefile or other backing store,
then "static".
If reading if s/r is enabled from kernel, then "dynamic".
In the future, we will allow the user to turn on suspend/resume
non-persistenly - not make it permanent by updating power.conf
(or whatever the future backing store will be).
So the setting of persistence is done in the library. It was also proposed
that the setting of persistence be done in the application; the
library when doing a getprop would be getting the property from the
kernel, not the backing store. If the value needed be be persistent
across reboots then it would
be the application that would be responsible for writing that out.
I think this would work if all the utilities and consumers of libpower have
different backing stores, but if all of them are reading/writing to a common
one, power.conf, then having the ability to do persistence in a standard
way to the same backing store in the common library would be best.
Do all the power utilities and daemons use power.conf for configuration?
Thanks
Margot
>
>
> Margot H. Miller wrote:
>> Please review/comment.
>> For those technology owners of potential consumers of this library,
>> please provide input.
>>
>> Thanks
>> Margot
>>
>> ***********************
>>
>> This document will outline what the major requirements are for a power
>> management library, called libpower. This is an Open Solaris sub
>> project of
>> the "Power Management Usability Interfaces"-
>> http://opensolaris.org/os/project/pmui.
>>
>> This library will provide a set of functions that can be used by
>> other Solaris
>> system utilities, daemons, and GUI's. Below are the functional areas
>> that the
>> library will be addressing. With respect to integration schedule of
>> this library,
>> we will be taking a phased approach on delivering functionality to
>> libpower.
>> The three major phases will be described below.
>>
>> There is also a whole area of usability that needs to be addressed.
>> The current process
>> is for a user to edit /etc/power.conf, modify some parameters, run
>> pmconfig
>> command to activate those properties. Not only are many of these
>> parameters hard to
>> understand but editing a file to turn on parameters is not very user
>> friendly. This
>> library will provide API's for power managment utilities that will
>> allow
>> a user to set the power management parameters via the tool, rather
>> than editing
>> /etc/power.conf. We assume the utilities that need this particular
>> functionality
>> are gnome-power-manager and the soon to be developed poweradm.
>>
>> In addition to providing an API for a utility to modify the
>> power.conf parameters, we
>> need to look at the parameters themselves. Are these the correct
>> superset of parameters? Can any of the parameters be removed because
>> they are no longer supported? Also with power.conf, the backing store
>> needs to be determined. Getting rid of /etc/power.conf and moving
>> it to
>> SMF is the very likely possibility. The issue of /etc/power.conf
>> and its parameters
>> and how the library will handle this, will be done in the second
>> phase of this library.
>>
>> First Phase
>> =======
>>
>> The first phase will deal with those API's that power management
>> system utilities
>> need. The first task is to determine what are all the Solaris power
>> management
>> utilities currently and what is being proposed in the future. The
>> potential
>> consumers of the library consist of:
>>
>> Consumer Source
>> -----------------------------------------------------------------------------
>>
>> /usr/sbin/sys-suspend /ws/onnv-gate/usr/src/cmd/power
>> dtpower ON
>> consolidation
>>
>> Gnome-Power-Manager JDS
>> consolidation
>> poweradm Not yet
>> developed powerd
>> /ws/onnv-gate/usr/src/cmd HAL
>>
>> The sys-suspend CLI was recently put back in March 2009 and a few
>> functions
>> in that utility are prime candidates for libpower as they seem to be
>> functions
>> that other power management utilities would benefit from. They
>> include checking to
>> see if a system is enabled to suspend, suspending a system, and
>> shutting down a system. We assume that these are the same type of
>> functions that are also duplicated in
>> dtpower and gnome-power-management.
>>
>> TASKS:
>>
>> 1) Identify all current and potential future consumers of library to
>> ensure that we have
>> their requirements.
>>
>> 2) Identify the common set of API's that are needed by all these
>> current and
>> future utilites, daemons, etc.
>>
>> 3) Identify API's that a particular utility/daemon need from the
>> library that
>> might be unique to that particular utility/library but still
>> appropriate for library.
>>
>> 4) After analysis of potential consumers of libpower, determine
>> which phase of
>> libpower integration proposed API's can go into.
>>
>> 5) Send spec out to Open Solaris power-dev alias for feeedback on
>> this spec and
>> proposed API's.
>>
>> 6) Work with security/auditing teams to figure out how auditing and
>> authorization checking
>> should be done.
>>
>> 7) Implement in libpower the functions in sys-suspend that can be
>> moved from sys-suspend
>> to the library, if it is determined that these functions would be
>> useful to other power
>> management utilities.
>>
>> 8) Implement in libpower those functions that a power managment
>> utility would
>> find beneficial and potentially useful for other future work.
>>
>> PROPOSED API's:
>>
>> Some of these API's are from sys-suspend utility and can easily be
>> moved into
>> libpower . We still need to determine what other API's should be
>> done in the first
>> phase that support the other power management utilities, daemons, etc.
>>
>> pm_poweroff()
>>
>> Halt system
>>
>> pm_reboot()
>>
>> Reboot system
>>
>> pm_halt()
>>
>> Halt system
>>
>> pm_suspend(mode)
>>
>> Actually suspend the system
>> With the future work of suspending to disk on x86, it seems
>> clearest to pass in a mode - suspend-to-disk or suspend-to-ram.
>>
>> pm_is_suspend_enabled(mode, session)
>>
>> Enabled because of power.conf setting "S3-support" to enabled or it
>> is a machine on the White List
>>
>> Session could be either "static" or "dynamic". There might
>> be other types of values for session in the future.
>>
>> If reading if s/r is enabled from statefile or other backing store,
>> then "static".
>> If reading if s/r is enabled from kernel, then "dynamic".
>> In the future, we will allow the user to turn on suspend/resume
>> non-persistenly - not make it permanent by updating power.conf
>> (or whatever the future backing store will be).
>>
>> Question to answer in the next phase of this library, is which of the
>> power.conf parameters should be allowed to be turned on
>> non-persistently.
>>
>> The below sections still need a lot of work, but since this is a "live"
>> document, these sections can be flushed out more later.
>>
>> Second Phase
>> ==========
>>
>> The second phase of this project will deal with power.conf and will
>> focus on usability
>> issues, namely are those the right parameters to have, what would be
>> the backing store,
>> how would a user change a parameter, getting/setting power managment
>> paramaters,
>> what are the power management facilities available on system currently.
>>
>> TASKS:
>>
>> 1) Research on Linux systems to see what the user experience is.
>>
>> 2) Review all parameters in power.conf. Are any of them obsolete?
>>
>> 3) Identify all consumers that need to be able to get/set power.conf
>> parameters.
>>
>> PROPOSED API'S:
>>
>> pm_getprop(value, session)
>> pm_setprop(value, session)
>> pm_listprops(session)
>>
>> Third Phase
>> =========
>>
>> The third phase would be providing API's that would help implement
>> power managment
>> policy- performance vs elasticity. A utility could call this
>> function to set
>> a policy of either performance or elasticity or a combination,
>> thereby letting
>> the user tune the system. Remote management of suspending a system is
>> another potential API for the library.
>>
>> This phase would also include other miscellaneous API's that were not
>> implemented in the above phases. This phase could also refer
>> to those API's that are related to suspend/resume but are not yet
>> critical for the library.
>>
>> PROPOSED API'S:
>>
>> pm_suspend_s3()
>>
>> If system's default is S4, attempt to enter S3
>>
>> pm_suspend_s4()
>>
>> If system's default is S3, attempt to enter S4
>> This would be needed when suspend to disk is implemented on x86 boxes
>>
>> pm_get_suspend_mode()
>> get the current mode of either S3 or S4
>>
>> pm_set_suspend_mode(mode)
>>
>> set the current mode to either S3 or S4
>>
>> The below suggested API's are from an email from Jedy. We are not
>> sure which phase they belong in but didn't want to lose this info:
>>
>> 1) API to get/set idle time after which the system will shutdown.
>>
>> 2) API to get /set idle time after which the system will suspend.
>>
>> 3) API to get/set idle time after which the system will hibernate.
>
