Hi Margot I would just like to add powertop(1) as a future consumer of libpower(3). The tool checks if CPUPM is enabled and allows the user to turn it on, if he/she wishes to do so.
Rafael 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.
