Fedora power management

[Sjoerd Simons]

On Tue, Nov 16, 2004 at 02:03:08PM -0000, Hughes R Mr (UG - Electronic Eng) wrote:
> >>     the /sys/acpi/toshiba/lcd seems highly Toshiba/ACPI specific (I
> >>     think that in 2.6.10 there will be some stuff for Thinkpads too,
> >>     that would rock.
> 
> Agree, and this is only the start. Do we really want lots of daemons 
> populating HAL with data, one for toshiba, one for thinkpads etc...
> 
> >>     So we may need to think about how to do this in a sensible way; I
> >>     guess, given it's 'actual make of laptop' specific, we may want this
> >>     functionality to live on the root hal device object representing the
> >>     computer. This device object may gain the capability lcd_display
> >>     and may export the interface org.fd.Hal.Device.LcdDisplay interface
> >>     with the SetLCDBrightness() property.
> 
> Sounds good to me :-)
> 
> >>  4. For actually suspending /org/freedesktop/Hal/devices/computer could
> >>     export the interface org.freedesktop.Hal.Device.PowerManagement with
> >>     the methods Standby(), Suspend() or what we decide to call them.
> >>
> >> On point number 4., exporting interfaces with methods, there are several
> >> options; here are some random thoughts
> >>
> >>  a. We could make use of D-BUS introspection though I'm not sure this is
> >>     finalised yet
> 
> Got a example URL? I’m not sure how this would be implemented cleanly.
> 
> >>  b. We could have a property, say, info.interfaces that is a list of
> >>     strings of exported interfaces, e.g. for computer it would be
> >>     (yes we would need to add lists as a type)
> >>
> >>      info.interfaces = {'org.freedesktop.Hal.Device',
> >>                         'org.freedesktop.Hal.Device.PowerManagement'}
> >>
> >>    and PowerManagement.xml would simply map Standby() (and typecheck
> >>    the method call) to a shell script or something that on ACPI does a
> >>    'echo standby >> /sys/power/state', and on PMU does something similar.
> >>
> >> This pretty much represents my thinking on how this should be done; I
> >> think it makes a lot of sense; it's extensible, sweet, concise and type
> >> safe. It may also be made secure by only allowing e.g. users at the
> >> console to invoke methods (on RH systems) or hald/D-BUS could integrate
> >> with other privilege systems (resmgr on SUSE for instance). So, to me
> >> it's an ideal interface for the desktop to do 'heavy-duty' operations/
> >> reconfiguration of hardware - the light-weight operations on devices
> >> (e.g. using them!) can be done through traditional ways.
> >>
> 
> Wow, sounds like a plan – very cross compatable. 
> 
> >This takes hal away again from just being a hardware monitor. Currently we're
> >trying to have hal run with the least amount of priviledges in Debian and
> >Ubuntu. With these kind of things, that would be very difficult.
> 
> I thought HAL was an abstraction layer, in which case Suspend() and Restart()
> is the ultimate abstraction usable on any system.  I run HAL as root (I’m
> pretty sure, I run fedora core 3) and I’m sure a lot of debian people would
> agree with the concept if they could unify their power management interfaces
> across architectures. Isn’t DBUS meant to have a security framework for this
> sort of thing?

Unification of power management is ofcourse nice. Pushing it all really inside
hal isn't necessarily the right way though.
> 
> >Instead of trying to do everything inside hal, one could image a seperate
> >deamon for various things (like for example network manager currently is)..
> >For
> >my powerbook i've been thinking to write a little program which manages
> >/dev/pmu by exposing a nice dbus interface to it and putting some information
> >in hal through dbus.
> 
> If I understand you correctly, this involves having different services for
> each power interface, one for LCD, one for Mac, one for ACPI, etc.  This is
> what I wanted to avoid. 

There is no reason why two different programs can't implement the same dbus
interface and service. Maybe all these methods can be implemented in one
program, maybe multiple makes more sense. 
  
> >In my opinion advantages of such small deamons:
> > * they can run least amount of priviledged (in the example,
> >   open /dev/pmu and drop privs)
> 
> DBUS can handle the permissions issue if I understand correctly.

What dbus handles is how a normal users communicated with a priviledged
process.. It doesn't handle the permissions the process itself has.

My main point is that hal should try to do everything in one big process.
Either some seperate deamon or something hal splits out. 

  Sjoerd
-- 
Research is what I'm doing when I don't know what I'm doing.
		-- Wernher von Braun
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal