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

[David Zeuthen]

Hi again,

I accentidentially hit "Send", more comments inline!

On Wed, 2006-08-02 at 11:47 -0400, David Zeuthen wrote:
> 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 driver detects that we really have no power left and the driver
makes the decision to power off the system. You can get away with
calling the method Shutdown on the HAL device
object /org/freedesktop/Hal/computer to achieve this.

> > * 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.

So, the addon is actually launched with super user privileges so you
don't need extra privileges at all. Unless the Debian hal package
doesn't work this way. Sjoerd?

It does make sense, however, to drop privileges to e.g. the haldaemon
user once you have opened a file descriptor to talk to the device. I can
put the haldaemon user and group in the .pc file yes?

> > * the current HAL namespace considers only battery/ac_adaptor, while
> > UPSs also have input, output, outlet, ... and various commands (see
> > [3])

OK, will check that out and follow up!

Cheers,
David