CPU Speed in HAL

[Danny Kukawka]

On Friday 25 November 2005 16:03, Richard Hughes wrote:
> On Fri, 2005-11-25 at 15:15 +0100, Danny Kukawka wrote:
> > On Friday 25 November 2005 12:10, Richard Hughes wrote:
[...]
> >  What's the
> > problem that the daemons poll for information? If you want to provide
> > current CPU freq with HAL you need to poll/read permanently from sys/proc
> > to have always the correct cpufreq. You can have multiple changes in
> > cpufreq per second.
>
> So? HAL doesn't require split-second accuracy of the current frequency
> -- polling one file every 60 seconds is probably okay. 

I this case the cpu freq property in HAL would be complete needless, bacause 
the value is nearly 100 % not up-to-date.

[...]
> > I'm not the only one who think powermanagement is, as already
> > networkmanagement (with Networkmanager), a big block of tasks which
> > should be moved to a extra solution/daemon or remain the exsting
> > solutions.
>
> This is an old argument. 

But's valid and not outdated.

> I don't need a whole powersave daemon, I just need a way to change the
> cpu frequency from session-space (without ugly hacks such as setting an
> applet setuid).

But as I sad before, why should we implement this to HAL because you don't 
need a powersave daemon. What is the next you need in g-p-m for 
powermanagement? Also implement in HAL? Why should we add only some parts to 
HAL if we can have a well working powermanagement daemon? What is so bad to 
talk via D-BUS to a system daemon for powermanagment? Why must we implement 
this is HAL? I don't understand this.

> If the consensus is that HAL shouldn't deal with cpufreq directly, then
> I'll look at how easily HAL can interact with powersaved or cpufreqd in
> the same way as we currently hibernate, using scripts. This does limit
> the API we can present, and may make it unsuitable for things like
> cpufreq applet and g-p-m to make full use of the hardware capability.

I'm not a friend of limited API, but as above: implement all in a specialised 
daemon and you get all you need. 

[...]
> > I'm completely opposed to this proposal. We should not integrate this to
> > HAL. What is the next? Volume control via HAL? Merge NetworkManager back
> > to HAL? Please don't implement all what you need in g-p-m in HAL. This is
> > not the solution.
>
> But just like with the battery.* information, there are ofter other
> users that could use this information and methods to reduce code, reduce
> errors and have one place where hardware quirks can be put.

You can do the same with a specialised damon and a DBUS interface.

> There is no way an applet should have to be setuid just to do something
> very simple with the hardware, and for a simple power management session
> daemon to replicate 99% of the cpufreq backend code just to spin-down a
> CPU to a preset limit.
> This doesn't just apply to specific applets and g-p-m, it applies to any
> future power-management daemon, program, script or whatever.

As Timo already sad: "Thanks to DBUS interfaces of a daemon you won't have to 
setuid anything."

> I know we differ in our thoughts of power-management (i.e. whether HAL
> should abstract specific hardware to a generic dbus interface), but I do
> appreciate the feedback. I'm just a new linux developer who sees stuff
> and says (maybe naively) "that sucks, we could do that better" when
> nobody has challenged it in years.

Yes we differ and I think we can make it better if we find a way to implement 
or extend a existing project to have the same standard for powersave as we 
have now HAL or NetworkManager in a own daemon.

Cheers,

Danny