[gpm] Re: [Nut-upsdev] Common Power Management with UPS support (was: NUT-NG)

["Arnaud Quette" <aquette dev gmail com>]

[this mail also replis to the NUT-NG answer from Niklas]

please keep the dest list Nikke.
This is still interesting for others than upsdev...

2006/3/15, Niklas Edmundsson <nikke acc umu se>:
> 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? ;).

the shared lib approach is a possibility (based on others ideas I've in mind).
but the same applies using the nut drivers as is, only having
sstate-hal.ch as difference. Also note that the shared lib approach
would not alter the driver code. There would be no special branch.
Only some compilation flags and rules, some #ifdef and that should
roll.

finally, the above approach complement the existing one.
NUT is, and will remain, portable and suitable for all possible systems.
But as its name implies, NUT is also a toolbox. So you can use it the
way you want, and integrate it the way you want / can. The HAL+DBus
approach on Linux is more than interesting as it allows to defer the
whole upsd/upsmon role to the system's power management. That would be
a good test bed for other systems (bsd, osx, ...). But obviously, that
only answer to the standalone case (1 UPS and 1 box). Moreover that
use case is far the more spread out. And the user still have the
option between nut-haldbus+cpm or the fullblown existing nut.

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

libtool is there for that

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

see above

Arnaud