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

Thu Aug 3 19:28:38 UTC 2006

2006/8/2, David Zeuthen <david at fubar.dk>:
>
> 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.

and the best is still to come ;-)

> > > 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?

possibly. I also have to check with libusb guys to create an
usb_open() using a physical path (ie /dev/bus/usb/XXX/YYY on linux,
/dev/ugenX on bsd, ...).
This way, hal can expose a *generic* physical path (simplifying
usb_device.linux.physical_path by removing the "linux" node)

After all, hal is a generic interface, so why bothering with systems
specific if we can handle these at a lower level...

> > > * serial and snmp drivers are not yet managed,

you once proposed me to sketch that one Dave ;-)

random thought: I'm thinking about relying on nut.conf (seen Jonathan
Dion's mail about the new NUT config?) for this fallback case and
having akind of /etc/modules to force hal loading for example
upsdrvctl (a nut driver launcher).

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

nut drivers only aims to acquire data and pass these to a control
layer that will act upon these, and possibly take the decision to
shutdown the system and call back the driver to poweroff the UPS...
Aren't there such a thing in ... the polkit or something like that?

my main concern here is not that it feasible or not (there is always a
solution), but if it will work also for dumb and all serial UPSs.
As dbus is killed early in rc0, only smart UPSs, which support delayed
shutoff (UPS poweroff), would work. Other, that do instant shutoff,
would simply crash the box. That's why the nut poweroff function is
called when everything is stopped and fs remounted RO.
I'll let this floating around in my mind a bit more...

I'll have to think a bit more about all these, and study how hal would
handle this (input welcome, as always).

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

ping me back when done, as I'm still addressing all this in background...

note that I would be pleased to see addon-hid-ups.c disappear for the
same reasons I killed NUT hidups and dropped my hiddev contribs (and
blacklisted MGE from hiddev support)... I can explain more if needed
but google might too ;-)
so patchs submission to nut are welcome...

Note that I'll merge this HAL branch in trunk when I got time to split
/ merge my big newhidups/mge-shut thingies.

And if everything go fine, this will be available in nut 2.2,
scheduled for the end of 2006.

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

NUT udev rules relies on a "nut" user that is only able to read/write
on the dev. Maybe simply using native udev rules would fixe that race,
and maybe adding the nut user to the hal group would be needed too.
I'll make some more test on these points and get back to you...

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

don't bother too much. I'll draft a spec with Dominique Lallement (MGE
and Chairman of HID PDC) about what evolution we should consider in
terms of futures devices kind and so needed data. Anyway, the NUT
naming scheme is a good reading ;-)

Arnaud
--
"Power is on the road, HAL and NUT drives it"
-- 
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/