Nut upsdev - Aug 2006 - Common Power Management : NUT and HAL (stage 1)

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/

Hi,

On Tue, 2006-08-01 at 15:41 +0200, 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.
This is very cool.
> 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)
OK, so for USB interfaces we pass all the properties in the environment
and I think what you want is

 usb_device.bus_number (in env. it's HAL_PROP_USB_DEVICE_BUS_NUMBER)
 usb_device.linux.device_number (similar name in env)

and use that in libusb to match on resp. the "location" variable in
"struct usb_bus" resp. the "devnum" variable in "struct
usb_device".
Will that work?
> * 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,
Right, so what is the use case here? The driver detects somethi
> * 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.
Right, there are some issues with that code I wrote:

 - it could use an family of functions in libhal to set multiple
   properties at once much like we have the function
   libhal_device_get_all_properties() that gives you a
   LibHalPropertySet you can iterate over. Right now it causes
   lots of roundtrips

 - addons in general should tell the hal daemon when the device
   is ready to be announced on the bus. Otherwise you get an
   empty device on DeviceAdded and all the properties will be
   added later. 

I will work on fixing that in the code in the HAL tree so perhaps just
waiting for that to appear in addon-hid-ups.c?
> * 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/
> _______________________________________________
> hal mailing list
> hal@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/hal

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@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>