[gpm] Common Power Management with UPS support (was: NUT-NG)
- From: "Arnaud Quette" <aquette dev gmail com>
- To: ups-dev-list <nut-upsdev lists alioth debian org>, "Richard Hughes" <hughsient gmail com>, "Stanislav Brabec" <sbrabec suse cz>, "GnomePowerManager List" <gnome-power-manager-list gnome org>, powermgmt-devel lists alioth debian org, "David Zeuthen" <david fubar dk>, "Thierry Thomas" <thierry freebsd org>
- Cc:
- Subject: [gpm] Common Power Management with UPS support (was: NUT-NG)
- Date: Wed, 15 Mar 2006 10:40:32 +0100
Hi fellows,
As the NUT-NG draft will take me more time than I currently have (I
found myself too optimistic since I got a baby ;-), below is the
beginning of an answer to the "Common Power Management with UPS
support" problem...
First, NUT is pure userspace code, for portability issue, and will remain.
USB is through libusb, snmp through net-snmp and serial through
standard read/write.
For nut-ng, I've thought about a common "empty" core (upsd) loading
pluggins (dll) according to its config, ie:
- standalone: upsd loads driver(s).so and localmon.so (non networked version)
- network server: upsd loads driver(s).so and upsmon.so (networked version)
- network client: loads upsmon.so (networked version)
I've not enough knowledges in DBus and HAL, but here is a draft idea,
based on the above arch., only considering the above standalone config
(the most common usage):
1) create a probe-ups.c which probe for USB (and maybe serial PnP [1])
UPSs. This one simply matches USB VID/PID against a known list
(driver.list)
Note that we (NUT) have to enhance the driver.list [2] file to include
that kind of info (ie usb:463/ffff => newhidups)
2) create and standardise a Common Power Management naming tree under
"org.whatever" (ie org.power) usable in DBus and elsewhere. The best,
at least to start with, would be to use the NUT naming [3].
3) create a addon-ups.c:
- this one replaces the above "empty" upsd and load the probed or
manually configured (in nut.conf or ups.conf) driver for the UPS.
Loading the driver means dlopen <driver>.so, and call upsdrv_main(...)
- the driver move toward shared object is not that hard, and remains
compatible with the NUT standard compilation. I mean that it would
simply be a set of compilation rules.
- this would however need to change the dstate layer [4] (driver state
is the driver API that implement socket communication with upsd) to
make it dbus (or hal-dbus) compatible.
4) the upsd / upsmon are not needed in this case. The driver submits
data to the DBUS, and then the Common PM layer use it.
5) we would then have 2 set of (conflicting) packages (ie on Debian):
nut(including nut-usb)+nut-snmp+nut-cgi... and nut-dbus (or nut-hal or
nut-cpm) that includes the <drivers>.so and a simple config file
(might be nut.conf, the future new config file for backward serial
compat.
That also means to change a bit the standard monitoring and config app.
This approach have to evolve for multi UPS support (ie 2 UPSs
protecting 1 box), networked client, and other cases NUT can manage.
More generally, I think the Common PM should evolve on the module notion:
you consider the a "power module" is a battery. But, for example, an
UPS can be composed of a battery, a boost/fade(buck) module, smart
outlets, ...
Moreover, UPSs have some RW variables embedded, and possibly some
commands (note that commands might be considered as RW vars. with enum
values, ie command.beeper={on,off})
And there might be other kind of power modules appearing in the future
(ie harmonic filter, solar panels, ...). So I would vote for a naming
like
org."power_or_whatever".modules.0.type={ups,laptop_battery,...}
org."power_or_whatever".modules.0.battery.* => see the nut battery
collection in [3])
This allows extension for redundancy management, and should be generic
enough for laptop batteries, UPSs, and future things.
Et voila... Note that this is a base, that we have to discuss it, and
that I would like all people interested to enter the loop (ie BSD and
KDE guys, ...). If you know somebody that is involved in Power
Management, please forward it to him and invite him to contact me.
I hope to have good feedback and reaction on it, though I'm currently
(and at least until the end of march) not much available...
Arnaud
--
[1] http://lists.alioth.debian.org/pipermail/nut-upsdev/2006-March/000776.html
[2] http://svn.debian.org/wsvn/nut/trunk/data/driver.list?op=file&rev=0&sc=0
[3] http://svn.debian.org/wsvn/nut/trunk/docs/new-names.txt?op=file&rev=0&sc=0
[4] http://svn.debian.org/wsvn/nut/trunk/drivers/dstate.h?op=file&rev=0&sc=0
--
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]