Mattia Dongili wrote:
Since cpufrequtils seems to be a subset of cpufreqd, and of each of them
main function's is to set the cpufreq governor that a cpu have to use (and
its options), shouldn't they conflict with each other?
no, cpufreqd does it dynamically, cpufrequtils statically and also
includes an utility to inspect the current state (cpufreq-info).
Yes, i know, but it creates an init scripts that ovelaps with that of
cpufreqd. Maybe cpufrequtils should not create an initscript if cpufreqd
is installed. Or should be a mechanism to make cpufrequtils to do
nothing on startup (a variable on /etc/default/cpufrequtils?).
As now the package's description is not very clear on what the package do
what's not clear about that?
See #433203. ;-)
the last one set (probably cpufreqd will prevail sooner or later as it
changes the limits/governor based on system stats)
It doesn't make sense to conflict with cpufreqd. As I see it these are
complementary tools and one may well have one of them or both (as I
have).
I could agree with you if the cpufrequtils would be only two utilities
with no init scripts. The fact that there is a (probably harmless) race
condition make me think that should be managed.
However i'd like to say that i'm not against cpufrequtils' init script,
because for a desktop system i like cpufrequtils a lot more than
cpufredq: in a workstation i only want to start ondemand governor (to
consume less power an make less noise on idle) and cpufrequtils make
this greatly, without configuring nothing.
Thanks for your work.
Cesare.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
