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
> >
>