Nut upsdev - Mar 2006 - Common Power Management with UPS support (was: NUT-NG)

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/

On Wed, 15 Mar 2006, Arnaud Quette wrote:
> 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.
The problem I see with the shared-library-idea is debugging. If things 
go severely bad (ie. overwriting memory wildly) you can drag more than 
the faulty driver down into the mess. Also, debugging/developing means 
restarting all drivers since they're shared libraries (unless you 
successfully is able to unload the library, but in a devel/debug 
situation you can't count on it). I've heard a lot of foul words from 
my colleagues about debugging shared library messes, so I'd prefer to 
avoid that frustration if at all possible.

So, I personally prefer standalone drivers for this reason, small and 
simple with built in fault isolation (aren't buzzwords nice? ;).

There's also a small portability issue, but those problems are fixable 
in most cases (I don't know about cygwin for example).

Currently, I don't see any gain in doing it the shared-library-way, I 
only see drawbacks.

/Nikke
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se      |     nikke@acc.umu.se
---------------------------------------------------------------------------
  Shin - Device for finding furniture in the dark
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=