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

[David Zeuthen]

Hi,

Sorry for the lag,

On Thu, 2006-08-03 at 21:28 +0200, Arnaud Quette wrote:
> > > > 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...

Yup, this sounds like a good idea. Heck, a libusb function where you
just pass a file descriptor to a USB device, interface or endpoint would
be nice!

> > > > * serial and snmp drivers are not yet managed,
> 
> you once proposed me to sketch that one Dave ;-)

I'll follow up on that in a separate reply (want to link to that mail in
the doc/TODO file)

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

OK, that makes sense and was really how I hoped the nut drivers works.
So the way this works today with g-p-m is that g-p-m monitors how much
juice / time is left in the UPS and provides the user with options on
what to do

 http://people.freedesktop.org/~david/g-p-m-ups-properties.png

maybe we want HAL to emit a signal when the power is low? I would be
fine with that.. However, I mean, we already can get to this by just
looking at the properties?

> 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'm not sure I understand this?

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

I'm more than happy to remove addon-hid-ups.c from HAL once there is a
NUT release providing drivers that HAL can pull in :-)

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

Very cool. Some questions about packaging. Ideally I'd like to see the
nut project being packaged in a way such that

 1. Distros like Red Hat and Debian can package nut such that there is
    a nut-drivers sub package that only contains the driver code, e.g.
    for the HAL case the addons and XML files so the addons are launched

 2. The nut-drivers package shouldn't provide anything but these. It
    also shouldn't need to create any users as the addons it provide
    will be launched as root and can drop to the haldaemon user once
    it opened the fd's it need...

 3. The motivation for this is that I'd like the HAL package on e.g.
    Red Hat to just pull in nut-drivers and, bingo, UPS'es will work
    out of the box. Specifically for normal desktop systems I'm not
    keen on having things like nutd because things like gnome-power-
    manager already provides this functionality.

 4. Users still wanting nutd (for server deployments etc.) can just
    install the main nut package to get nutd back. It should be able
    to happily coexist with e.g. g-p-m.

What do you think? Maybe it's already feasible to package it up that
way?

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

But with HAL the addon is already launched as root so we don't need to
change permissions on the files, yes?

I supposed that nutd can run unprivileged since we already allow anyone
to read from HAL. However, maybe nutd needs more privileges for other
things?

> > > > * 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 ;-)

OK, that sounds good. I'm happy to have the NUT drivers populate a lot
more properties on the hal device object - we can just link to that doc
from the hal spec for the description of these properties.

Cheers,
David