DeviceKit-power future plans

[Richard Hughes]

On Tue, 2008-08-05 at 16:09 +0200, Arnaud Quette wrote:
> > * 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?

Well, a way for other bits of code to create virtual devices that don't
exist in sysfs. Maybe a dbus bridge. Not sure. I don't want to over
complicate things.

> > * 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!

Sure, I appreciate that. As soon as you put topology into DK-p, you've
got to configure it. And then you need graphical tools. This isn't that
interesting to me -- for me this is a new application/server layer
_over_ devicekit, using the values from devicekit. The multiple UPS
scenario is a pretty special use case with people wanting very different
things.

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

Sure, if they make sense then I don't see why not. I've not exported
them so far as nothing needed them, but I don't think adding another two
things hurts the interface.

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

Right, I don't think you can fix all the usecases from a embedded device
to a big iron server in one reporting agent. You don't want policy in
such a reporting agent as we've seen how this can fail.

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

Well maybe. I've talked with people at Nokia about HAL, and it only
makes sense if they can rip out 90% of the unused functionality and make
it very quick and use almost no RAM. Embedded is a difficult sector.

> 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

I guess outlets is another interface on power, that's sort of sane I
guess.

> IIRC Richard, the
> unit I provided you (evolution, right?) as these manageable outlets...

It's an Ellipse 750. I've never tried managing the outlets, any hints?

> - 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 emailed the list about meta-devices, I'm not sure if DavidZ wants
these as part of DK. We'll see. :-)

Richard.