CPUFreq addon in HAL

Holger Macht hmacht at suse.de
Fri Jul 14 12:44:19 PDT 2006


On Fri 14. Jul - 11:28:06, Artem Kachitchkine wrote:
>
> >Personally I think it makes sense to add. I'm unsure how this is handled
> >on FreeBSD and Solaris? It looks to me as the interface is sufficiently
> >abstract.
>
> I have no idea what a CPU governor is. So if you like litmus tests, here

So how are CPU frequency adjustments done on solaris if at all? Can you
elaborate a little bit so that I can get a basic overview?

> you go - the interface might not be abstract enough :)
>
> HAL's main role being to abstract, I think we need to keep naming
> functional. E.g. menu items "Web Browser" and "Email" are functional,
> "Firefox" and "Thunderbird" are not. In addition to being more clear, it
> also provides abstraction and the ability to substitute Firefox with,
> say, Opera without confusing the users. So perhaps instead of "governor"
> we could use "policy" or something like that.

The naming shouldn't be the problem. The problem I see is that this
governor setting is not exclusively policy decision. For example you can
have a ondemand governor (frequency control in kernel) or a userspace
governor (frequency control in userspace by the addon). Both provide the
same policy but with a different mechanism.


> I would also like the interface to be more self-descriptive, sort of
> like XML is. Instead of hard coding 1-100, have properties for min and
> max values (and maybe default value, too).

Something similiar to a configuration file? I really think that 100
different steps should be sufficient for every purpose I can think of.

And there's a default value, 50. We just have to make this clear in the
spec.

> How does my OS-neutral desktop application know the name of the (lets
> say) policy to set with SetCPUFreqPolicy()? Maybe the interface should
> list available policy names as a strlist property (which could go into a
> drop-down box in a GUI).

Yes, the desktop application would need some knowledge about what the
different mechanisms provided actually do. And that's bad for a OS-neutral
app, of course.

And yes, we are currently talking about exporting the different
Governors/Policies via HAL. See the discussion about we should use HAL
properties or DBus methods.

I really see a problem in regard to all this. I have to think about it a
little bit more and await your reply/other comments.

[...]

Regards,
        Holger


More information about the hal mailing list