G-P-M on the wrong track?!

[Holger Macht]

On Mon 17. Oct 11:58:35, 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.
> 
> It shouldn't be that hard to extract the functional bits from g-p-m and
> put them into a daemon.  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.

We tried hard the last months to clean up the powersave daemon to
"prepare" it for other developers and other distributions. In first place,
this included documentation cleanups, code cleanups and redesign of some
parts. This is now nearly finished. So for anyone who wants to have a look
at the code, it would be the best to use the most recent cvs checkout.

> 
> 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.  
> 
> 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.

Atm, we are just gathering information lying below /proc/acpi for battery
and the ac adapter on demand. There are two reasons why we do not do more
with hal yet:

	1. We read out all information ourselves in the past in library
           functions. To provide some sort of compatibility period with
           people not using hal yet, we just tried to do the things we did
           in the past on ourselves with hal now and made it configurable
           at compile time.

	2. Second reason, and the one more important I think, is that I
           was never sure whether hal stays the same over time. I am
           sceptical whether some things might get removed in future or
           not because there is another approach for hal then defined in
           the spec atm.

Planned in the near future (1-4 weeks) is the full integration of hal and
dropping of the old code. Full integration means getting informed about
device and property changes and reacting on them (;ike ac adapter
plug/unplug). But like mentioned above, the redesign of the powersave
daemon to invite other developers is nearly done. New features are always
welcome if appropriate.

> 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.

As already mentioned in another mail regarding this thread, this concept
turned out to be practical and useful. But opinions differ...

[...]

Regards,
	Holger