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? > > The idea here is to provide a library that can be linked against to do everything that power.conf does today. Applications can then make use of that library and a CLI/GUI provided that admins would use to configure the system. Eventually, power.conf would be EOL'd. >> 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? > > "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? > > >> 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? > >
The idea here would be to make the debugging of suspend/resume easier than it is today. This would help developers of drivers. > thanks, > -jane > > > Thanks Joe Townsend >> 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 >> >> >> > > _______________________________________________ > pm-discuss mailing list > pm-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/pm-discuss >
