[Nut-upsdev] Common Power Management : NUT and HAL (stage 1)

[Peter Selinger]

Hi Arnaud,

> 3) Some limitations and remainders
> -------------------------------------------------
> * we can't support multiple identical UPS (== using the same driver!)
> for the moment, due to the fact that we use the "auto" value for the
> port. We will need a way to get the needed info (maybe a physical
> path, but we don't manage this in NUT USB drivers for now)

Basically, I have no idea what HAL means or what it is good for
(wasn't that the name of the computer in "2001: A Space Odyssey"?).

However, I think that newhidups can handle multiple identical UPS's.
The user can make a configuration for each device via the vendor,
product, serial, bus mechanism; identical devices can be identified by
serial number and bus. Also, it is not mandatory to use "auto" as the
port value; since the port value is ignored, the user should be able
to use "auto1", "auto2", or any other names. 

-- Peter

Arnaud Quette wrote:
> 
> Hi fellows,
> 
> I'm really pleased to announce that a first stage of NUT and HAL [1]
> integration has been reached: NUT drivers (in fact, only newhidups,
> tripplite_usb and bcmxcp_usb for the moment) can feed HAL data.
> 
> It's a "quick and dirty" hack, as a proof of concept, and there is
> still lots of things to be done, both on NUT and HAL sides.
> But it's a good base, and very promising for future developments on this side.
> 
> Some details on how it works:
> 
> 1) How NUT drivers are architectured
> ---------------------------------------------------
> The NUT drivers are composed of 3 parts:
> * the core (main.ch) which is the same for all drivers, and only call
> drivers specific functions,
> * the dstate layer, which allows the state socket communication with NUT's upsd
> * the drivers specific functions, ie mge-shut.ch, apcsmart.ch, ...
> For more info, see [2]
> 
> 2) How the HAL bridging is done
> --------------------------------------------
> * switching to HAL is as simple as wrapping HAL calls into a dstate
> fake (dstate-hal.ch) and modify a bit driver's main (main-hal.ch) to
> do the HAL init and specifics.
> So it *doesn't* touch the drivers code at all.
> One code base to rule them all ;-)
> * each time the driver calls dstate_setinfo() to add/update a data, a
> lookup function will translate it into HAL data, using a lookup table
> in dstate-hal.c
> * the same goes for status_set(), for updating UPS status data.
> 
> 
> 3) Some limitations and remainders
> -------------------------------------------------
> * we can't support multiple identical UPS (== using the same driver!)
> for the moment, due to the fact that we use the "auto" value for the
> port. We will need a way to get the needed info (maybe a physical
> path, but we don't manage this in NUT USB drivers for now)
> * serial and snmp drivers are not yet managed,
> * upsd compatibility layer, reading data from HAL, hasn't been done,
> * UPS poweroff function isn't called (which is an enormous lack!).
> This point needs some investigation with HAL guys,
> * the exposed data might be wrong, and some others lacking. I've for
> the moment made the same thing that is done in the current HAL
> addon-hid-ups.
> * I'm facing a race condition between udev privileges settings and the
> addon launch by HAL (need a sleep(2) in main-hal() to give time to
> udev to set the perms). This might be due to the current script I'm
> using on Debian, which mix hotplug and udev support (so shell script
> exec is a bit slow!). Maybe using native udev rules would solve this.
> * the current HAL namespace considers only battery/ac_adaptor, while
> UPSs also have input, output, outlet, ... and various commands (see
> [3])
> 
> 
> 4) For the brave who want to test
> ---------------------------------------------
> * svn co svn://svn.debian.org/nut/branches/HAL
> 
> * install libhal-dev
> 
> * "./configure && make hal" from within the nut dir
> 
> * copy the file drivers/hald-addon* to the HAL addons directory (ie
> /usr/lib/hal/ on Debian) or equivalent dir.
> 
> * copy the scripts/hal/20-ups-nut-device.fdi file to
> /usr/share/hal/fdi/information/20thirdparty/ (still on Debian) or
> equivalent dir.
> 
> * modify your hotplug/udev script so that the HAL user can read and
> write to the usb device (ie /dev/bus/usb/XXX/YYY)
> 
> * restart HAL (ie using "/etc/init.d/dbus restart"). I've personaly
> used "killall hal" and restarted it using "hald --daemon=no
> --verbose=yes" to see the beauty very verbose
> 
> * You should now see the UPS using:
> - [kde-]hal-device-manager,
> - gnome power manager (standard applet for battery management), which
> will state that there is an UPS
> (kudos to Richard Hughes;-)
> 
> 
> I'll try to post a more complete spec link by the end of august.
> 
> Meanwhile, any comments/feedback is welcome.
> 
> Arnaud
> -- 
> [1] http://freedesktop.org/wiki/Software_2fhal
> [2]  http://eu1.networkupstools.org/doc/2.0.1/design.html
> [3] http://svn.debian.org/wsvn/nut/trunk/docs/new-names.txt?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/
> 
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>