Re: CPU Frequency Scaling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2006-12-04 at 15:35 -0500, Jon Nettleton wrote:
> On Mon, 2006-12-04 at 15:19 -0500, David Zeuthen wrote:
> > On Mon, 2006-12-04 at 21:10 +0100, Miloslav Trmac wrote:
> > > If the system administrators have the choice between
> > > 1) writing a shell script that echo(1)s settings to files in sysfs,
> > > 2) writing a shell script that writes them to gconf (which is more
> > > complicated and not as easy to test as cat()ing sysfs files), running
> > > g-p-m and gconfd,
> > 
> > The proposal was that g-p-m would ship with a set of commands that would
> > do the heavy lifting, e.g.
> > 
> >  # gpm-set-cpuscaling ondemand
> 
> Is that a temporary setting, or does it stick over restarts?  

It would stick over restarts; it would just be modifying the system-wide
defaults gconf setting that all instances of g-p-m would read.

> Can a user
> that logs in override it? 

Yes. 

It's just gconf, an user can override settings unless they are the
setting is set in the mandatory layer. Resolving settings currently
involves three layers 

 1. System-wide mandatory settings
 2. Per-user settings
 3. System-wide defaults

in that order. E.g. if a setting is in the mandatory layer, we don't
consult the user, system defaults layers.

(for doing this we'd probably stick a fourth layer in called "Factory
defaults" e.g. the settings we ship with and currently install as
system-wide defaults. This is easy and to avoid .rpmnew/.rpmold problems
when a user modifies system-wide defaults. I believe Debian does this
already.). 

For more information on gconf see

 http://developer.gnome.org/feature/archive/gconf/gconf.html
 

> What is that command? 

It's not written, it was an example. I'd expect initial incarnations of
it to just be a 10-line (and that's probably too high) shell script that
invokes gconftool-2.

> Before I say anything
> about it I would love to see what is planned.  Are there any use cases
> posted to a wiki somewhere?  I think we could have a much more
> productive conversation about where Fedora is going if we all had a
> little more information.  We are a community driven distribution right?

Everything written down is pretty much still in the GNOME bug I posted a
link to. I'm busy with other things (RHEL-5, LiveCD,
fast-user-switching, new hal+ PolicyKit+ConsoleKit releases, Christmas,
LCA, emergency bug fixing) until February but feel free to create a Wiki
page about it and post it to the list.

Certainly, if anyone is to do such a thing one would be posting the
proposal to f-d-l just like I did for fast-user-switching and, recently,
live cd work. I just mentioned this thing to shed some light on some of
the plans we have upstream and avoid duplication by introducing more
confusing ways to configure power management. 

Whether Fedora wants to use that or not is another matter.

     David


-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux