[PATCH] sched: mc/smt power savings sched policy

David Zeuthen david at fubar.dk
Mon Jul 2 16:47:43 PDT 2007


On Mon, 2007-07-02 at 18:45 +0200, Holger Macht wrote:
> What I would like to see is maybe an additional addon containing all these
> settings. And it would also be good to use the infrastructure provided by
> the CPUFreq addon for this (all the dbus_* methods for instance). At a
> minimum, the functions/D-BUS methods provided in the patch need a proper
> prefix/infix and need to be put to a different source file (I will comment
> on other smaller issues in the patch as soon as we've sorted out
> everything).

Yeah, HAL is sorta-kinda extensible in this way; I mean, if S.Çağlar
wants this, I think the path forward here is to put this in another
add-on (that is not necessarily part of the HAL source tarball. Then it
can also be released more frequently; no need to block on slackers like
me.)

     David

ps. : This is somewhat off-topic but related: one of the problems we
have with HAL.. a problem that I failed to anticipate / identify
earlier.. is that everything (and HAL now does a lot of things for
better or worse) is part of the same tarball / source tree. It makes me
as an individual a bottleneck.. especially when I'm unavailable.

On the other hand we have this kinda-sorta coherent model that makes it
easy for consumer projects like NM, g-p-m, KDE, kpowersave etc. to pick
up new features; I mean, a new feature is most of the time just another
set of properties to inspect, another D-Bus interface to peruse, e.g.
few changes in application code to take advantage of the new feature.
Having a model like this allows us to plug in new layers (like
ConsoleKit, PolicyKit) and retain some aspects of centrally controlled
management.

Anyway, this is something to keep in mind and learn from the next time
we break stuff.. last time we really broke stuff was going from 0.4.x to
0.5.x which now is several years ago. And I think we soon need to at
least solve the "davidz is a bottleneck and is always slow making
releases" problem. I really don't like it anymore than you guys and I
think it would be nice to have others on this list be responsible for
releasing code they know a lot better than me, e.g. it Holger, Richard
and others are a lot more versed in the power management side of things.

Something to think about.

      David




More information about the hal mailing list