G-P-M on the wrong track?!

[Richard Hughes]

On Mon, 2005-10-17 at 11:58 -0400, John (J5) Palmieri wrote:
> On Mon, 2005-10-17 at 15:53 +0200, Danny Kukawka wrote:
> > On Monday 17 October 2005 14:42, you wrote:
> > > > This is what we do with powersave [1] on SUSE and ALT Linux. There is a
> > > > (desktop and arch (ix86, ix86_64, ia64 and now also ppc) independent)
> > > > daemon which only do powermanagement and which also do powermanagement if
> > > > there is no desktop user logged in.
> > >
> > > What use case has this got? How many times on battery do you leave your
> > > laptop at the login screen? There was talk of integrating g-p-m with gpm
> > > so that it runs at the login prompt (with the preferences of root), but
> > > I'm not sure how far this idea actually got.
> > 
> > This is a needed feature. There are not only laptops on battery. This was only 
> > one example. Other expample: You run you laptop on AC or your desktop machine 
> > and want to suspend or change cpufreq or set a special powerscheme as 
> > user/root without login to desktop. There are many possible use cases. We 
> > know this requirement from develop powersave and SUSE users since the start 
> > of the project. There are also several user which want to use the daemon 
> > without login from a script and also this work well with powersave.
> 
> This makes sense.  After rethinking my earlier assessment there are a
> couple of reasons to have a separate daemon.  First is security, with a
> separate daemon we can define who can talk to it a lot easier though I
> am not convinced what HAL does right now is of any risk.  Second is your
> point about non-loggedin behavior.  There is no way for the HAL addons
> to set policy so even if we kept the functionality in HAL a client
> daemon would still have to be run as root.

What about running a non-gui (i.e. just console) version on g-p-m when
the get the the gdm login screen? The root user policy can be the policy
when no user is logged in. This is not a typical use case for me, and
I'm guessing most other laptop users so it is not a big concern.

> It shouldn't be that hard to extract the functional bits from g-p-m and
> put them into a daemon.

Erm.. In theory no, but actually doing this is a right hassle. You have
to define *lots* of different structures and methods and it all gets
really horribly rather quickly. I've tried doing it this way, I showed
DavidZ the idea and code, and he said it was a crazy idea (he said "It's
crack" I believe...) and we might as well get the direct values straight
from HAL.

>   I don't know if powersave is the best place or
> not.  It looks good but I am concerned about powersave trying to do too
> much but then again I only took a five minute glance at the code.
> 
> After reassessing, HAL should definitely remain the canonical source for
> all information on management devices with the daemon being used for
> system wide default policy and interface for overriding that policy by
> logged in users (or scripts, or whatever).  In other words as stated
> elsewhere in this thread we need a constant D-Bus interface and a daemon
> that implements it.  It shouldn't be hard in the short term to make g-p-
> m's functional bit into a daemon and then in the long term perhaps merge
> powersave and the daemon part of g-p-m.  I think the design goals are
> all the same and this is just implementation details.  

But the implementation details are the bits that make the design
invalid. It no use having a beautiful design if it's unimplementable.

> How far along is powersave in using HAL as the source of device info?
> Merging the bits that HAL doesn't do would be good.  

Then effectively you are reading in values from hal, and then
re-processing them.. It's a whole lot of duplication of effort. It's not
difficult to work out if a laptop is on battery charge using HAL
(because of the abstraction of APM, PMU, and ACPI), so I don't see why
we need a little system daemon to do it for us.

> This is all stuff that is just better if we all collaborate on one
> solution.  The client are different but on the backend it seems
> worthwhile.  Powersave should really be moved to fd.o if we do go down
> that road but that is a different issue.

Too many people want different solutions, doing different things.
I'm of the opinion that code speaks a thousand words, so "great plans"
do not get me motivated. A good design, with clear use-cases, and well
commented, easy to read code would be the best argument for me.

> Richard is this all good with you?

In it's current state, no. I still do not see any compelling reasons to
split pm into user and system state.

thanks,

Richard.