On Wed, 5 Nov 2008, Jane.Chu at sun.com wrote:

> Hi, Randy,
> 
> I'm not voting(don't think I can),  just try to understand  the project
> better.
> 
> Randy Fishel wrote:
> 
> > I would like to propose the following project to be sponsored by the Power
> > Management Community Group:
> > 
> >    Power Management Usability Interfaces
> > 
> > Controlling and managing Power Management facilities currently is a small
> > collection of diverse tools that often manipulate objects directly, or even
> > require that a user edit a configuration file.  And many don't allow the
> > user to identify or understand in-kernel values without entering a debugger.
> > As some tools need to duplicate pathways, maintenance becomes a problem as
> > all the tools need to be identified and updated.
> > 
> > Providing a well defined set of interfaces help to aleviate confusion, and
> > promote easy to use and easy to create tools.  Maintenence and security are
> > also often confined to the element that exhibits the problem.  Some of this
> > work may just result in improved documentation, but there will also be a
> > need for new and updated tools and interfaces.
> > 
> > I see this work falling into four distinct areas:
> > 
> >    A Power Management specific library (i.e. libpower)
> >      Provides a committed set of programatic API's that
> >      can be consumed by other tools, utilities, daemons, and GUI's
> >  
> 
> What set of existing & new functionality that you have in mind to be provided
> by the APIs?  powerd and part of pmconfig, I suppose?

  powerd and pmconfig are likely to be directed to the Commands and 
Utilities area, but for libpower, the various operations that they 
perform with the kernel would go through API's defined by libpower.  
So to some extent, existing functions in these commands would be moved 
to libpower so that they might be used by other applications.

  New functionality would be property manipulation (both for a running 
instance and the file(s) that saves the these properties), better 
wrappers to actions such as suspend, I/O, and CPU's, including dealing 
(and possibly managing) authorizations.

  But for the most part, I expect the project to evolve what all of 
these usability items can and/or should be.  I have some initial 
thoughts as to what some of the API's should be, but I don't want to 
limit to those, as well as keep an open mind if another contributor 
has a better suggestion.

> 
> >    Commands and Utilities
> >      Predominantly updated and new CLI's, but could also be GUI's
> >      that are expected to directly be us
> > 
> >    SMF facilities
> >      New and improved services that can act standalone, or be
> >      used as a repository for running state.
> >  
> 
> Are you referring to the SMF notion of repository for running state?  if yes,
> how do you imagine how user might exploit that?

  Yes, and it could certainly be used as a replacement for power.conf 
(which would be transparent to users of libpower).  One value of SMF, 
is that the user doesn't actually manage text files, so properties can 
be validated well before they are passed to the kernel, and without 
redistributing a large set of new files should these properties 
evolve.

> 
> "power" is already an SMF system service, are you proposing an alternative or
> modification to the service?   If the latter, what specifically you'd like
> to change?   Laslyt,  how may virtualized platforms exploit the service
> differently than it does now?

  Possibly.  Currently the 'power' service is for the starting and 
stopping of powerd.  It could be choosen to expand this to cover more 
aspects of 'power', or other services could be generated to support 
different aspects of power management.  Either of the above would be 
the good place to set policy (could even be leveraged by the new 
Storage PM project :^> )..

> 
> >    Debug/Observability
> >      Some of this might land in CLI, but could well include mdb
> >      and dtrace enhancements (i.e. dtrace pm provider).
> > 
> >  
> Do you plan to tie up the "Observability" functionality to the "powertop"
> ported to Solaris by way of expanding it perhaps?

  This would be one of the observability items.  It could also be 
where monitors would be defined which could be used to provide 
feedback to controls (i.e. a temperature monitor that would drive cpu 
frequency down if the temperature gets too high).  It would also be, 
as Joe points out, where to define tracing, to make any power 
management facility, not only suspend and resume, easier to debug.


  But to reiterate, I expect the project to evolve all of these items, 
and make appropriate architectual and code cases to the proper review 
body (PSARC, PM CG, ON, OGB, etc.)

  Cheers!

        ---- Randy

> 
> thanks,
> -jane
> 
> 
> > Initially I expect this work to focus in libpower, but there is the
> > likelyhood of effort in the other areas, as well as short-term binary
> > relief.  This project will not necessarily limit itself to the above areas,
> > and could easily expand as the need presents itself.
> > 
> > 
> > 
> >  Comments?  Votes?
> > 
> > 
> >  Cheers!
> > 
> > 
> >     ---- Randy
> > 
> > 
> > 
> > _______________________________________________
> > pm-discuss mailing list
> > pm-discuss at opensolaris.org
> > http://mail.opensolaris.org/mailman/listinfo/pm-discuss
> >  
> 

Reply via email to