DeviceKit-power future plans

[Arnaud Quette]

Hi Richard and everybody,

2008/8/5 Richard Hughes <hughsient at gmail.com>:
> You might have noticed [1] I've spent the last couple of days working on
> DeviceKit-power. It's now more than just a bare shell, and has 80% of
> the functionality of HAL. I'll spend the majority of today also working
> on it, and hopefully them I can start porting gnome-power-manager to use
> the new code.

thanks for pushing that effort ;-)
I've sadly not had a chance yet to get this new code (no more inet
access at home, and a big move at work with no git access yet)

> Changes I have done:
>
> * split apart some of the logic into separate GObjects and object
> structs for modularity
> * add the suspend and hibernate hooks in properly (just supporting
> pm-utils) -- quirks still to do.
> * Move a lot of the time prediction stuff in g-p-m down into DK-power
> * Made it trivial to get system battery state (HAL is hard)
>
> Changes I want to do:
>
> * add a proper unit test suite
> * add the UPS hooks for either NUT or direct access

what do you mean by the direct access and this hooks?

> * share some common code where it makes sense, e.g.
> compute_object_path_from_basename and the sysfs stuff
> * maybe add in the kernel pm_qos stuff for power saving, as it fits
> quite well in the DK-power architecture.
> * add helpers for stuff like CSR mice and kerboards (maybe)
>
> The things I am most concerned about are:
>
>  * bloating the public D-Bus interfaces
>  * avoiding feature creep by adding power device topologies or support
> for obsolete technologies (/proc/acpi, /dev/apm)

though keeping things simple is a good idea, the notion of PD
topologies is useful to handle complex power chains (several UPSs and
PDUs (~smart strips) cascaded for example). As an example, 2 UPSs
grouped in serial mode doesn't give the same result as 2 UPSs in
parallel mode!

I also think (in reply to DavidZ questions in the spec) that we should
expose all the raw data (voltages, frequencies, ...) and not be
filtering these, since some apps might need these.

my main concerns is that we should be able to smartly address all kind
of power devices (comprising future things such as solar/hydrogen
modules)  and all kind of setup (from the simple desktop/pda with 1
embedded battery to the iron server with several UPSs and PDUs). The
composite Power Module approach I've introduced before would help
there (see below).
So let's keep things simple for the simple case, but keeping the
capability to expose advanced data for advanced usage/users.

I still find this new naming too simple and non expandable compared to
the nested naming approach of DBus and the old HAL (X.Y.Z instead of
X-Y-Z)
for the recall, here is the list of data a UPS can expose through NUT:
http://www.networkupstools.org/doc/2.2.0/new-names.html

another small example: linux is more and more present in appliances.
So we can seriously imagine such a in house dedicated power management
modules running dk-p...

> Hopefully in a few days time DK-power will be able to do all the stuff
> HAL can do, and a little bit more. I'll post another mail when there's
> more to show, but here's a nice teaser:
> (...)

some more info about the composite Power Module approach:
- a Power Module is either a simple or composed device.
For example, laptop batteries are simple batteries, while UPSs are
ac_adaptor+battery at least, optionally input+output+outlets+ambient
sensor
- the outlet collection is available if the device has this
capability, and allows an advanced power management by powering off
some devices depending on some default / user config (like power off
the outlet of the printer/scanner if these devices haven't been used
for 5 minutes, and power these on on demand). As power costs more and
more, avoiding simple standy is really interesting! IIRC Richard, the
unit I provided you (evolution, right?) as these manageable outlets...
- the mandatory (and simple) info could be exposed (possibly
duplicated) at the top level of the Power Module, the same way as in
USB/HID PDC approach of PowerSummary. Thus, if you only need basic
info, you query this. And if you need the full set of data, you query
the full Power Module tree (which includes all the above mentioned
collections)
- we can have one or more meta devices: at least a top level one that
expose a consolidated runtime, and some lower level ones (consider an
iron server with 2 power supplies, and 2 UPSs per power supplies => we
can have 2 meta UPSs (one per power supplies) and a top level one
consolidating the data from the 2 lower meta ones...)

I've tried to make things simple, but I lack time and it's always hard
to explain complex technical notions in non lengthy mails...
so don't hesitate to ask questions. a meeting (at least online or by
phone) would certainly be a good thing too!

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - MGE Office Protection Systems - http://www.mgeops.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/