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. -- This message posted from opensolaris.org
