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

Wed Aug 2 15:47:12 UTC 2006

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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/hal