[Nut-upsdev] Re: Common Linux Power Management (HAL and NUT) (was: Re: ideas for a new UPS infrastructure)

[David Zeuthen]

Hi,

(adding the hal list as Cc)

On Wed, 2006-05-24 at 23:42 +0200, Arnaud Quette wrote:
> Hi David and fellows,
> 
> I'm reviving this important thread about a common power management.

Sorry for taking so long to respond. I agree it's important too!

> To sum up, the first aim is to allow a better user experience on Linux
> by bridging NUT with Linux HAL, and Gnome Power Management / any PM
> GUI.

Right.

> But it also initiate a bigger investigation about how to integrate NUT
> support for UPSs into the native OS Power Management infrastructure
> for all supported OSs, while keeping NUT compatibility (ie nut server
> on Linux and nut clients on Solaris, ...).

Yeah, notably, since the last time we discussed this, HAL is gaining
support for FreeBSD and Solaris. It seems to be coming along nicely.

> 2006/3/10, David Zeuthen <david at fubar.dk>:
> >
> > Hi,
> >
> > I'm the HAL maintainer.
> >
> > On Fri, 2006-03-10 at 00:29 +0000, Richard Hughes wrote:
> > > > Only in NUT:
> > > > - network UPS support
> >
> > See below
> >
> > > > - more UPSes, more machines policy
> >
> > Yes. g-p-m relies on HAL to get this and I don't think this should
> > change for UPS's attached via e.g. USB. To give some perspective the HAL
> > support for UPS's is something I wrote in one or two evenings; it's a
> > very simple piece of code
> >
> >  http://webcvs.freedesktop.org/hal/hal/hald/linux2/addons/addon-hid-ups.c?rev=1.12&view=markup
> >  (yes, this code could need some love.. I know!)
> >
> > Hence, we only support USB UPS's supporting the HID protocol. I don't
> > really know how many that is (10%, 20%? Only home users?) but I'm
> > curious to know :-)
> 
> I'm too ;-)
> we recently added support in nut for USB units not complying to HID
> (powerware, tripplite, ...) but our hid driver supports MGE, APC,
> Belkin and CyberPower), with some advanced features.
> 
> > I think it could be really cool to use the code in NUT in HAL since we
> > would support a lot more devices. But I'm not really sure how we would
> > do that?
> 
> I've lots of ideas about that ;-)
> 
> > Does it rely on kernel drivers? Userspace code? etc. I'd love
> > to know.
> 
> as told previously, nut is pure userspace.

Cool, so implementing support in HAL would amount to adding a "HAL
addon" that speaks to the device.  Said addon can also handle methods on
the device e.g. one can call DisableSpeaker() on the org.fd.Device.UPS
D-BUS interface to configure the UPS. 

But it's probably to early to talk about API details just yet.

> > Btw, I'm not sure how we would support UPS on the serial port in HAL.
> 
> see below
> 
> > One thing about HAL is that we can never have a configuration file
> > saying where to look for devices; the whole philosophy about HAL is to
> > detect your devices and present the desktop bits with an extremely
> > well-defined view. I got some ideas about serial ports if you're
> > interested in cooperating; basically I think it's doable the same way
> > e.g. Windows lets the user search for a modem on the serial port. I can
> > expand on that if you want me too.
> 
> more than interested in. I also have the same approach in mind.
> but we should limit to USB and keep known serial PnP units (ie MGE)
> for user request (ie a check box "autodetect serial units (MGE ...
> only).

Right. I think this is doable, want me to sketch out how I like to do
this in HAL? 

(as the solution must also work for detecting serial mice, serial
modems, serial GPS readers, etc., it's a bit complicated but still
doable and nice)

<snip>

> I've another thing in mind. To get the picture, have a quick look at
> NUT "layering": http://eu1.networkupstools.org/doc/2.0.1/design.html
> 
> The base:
> - all the UPS specific is handled by NUT, which limit work (no
> duplicated codebase), and potentialy give support for UPSs of all
> kind.
> - we _must_ keep NUT compat at upsd/upsmon level (read theim runnable)
> in the long run, for linux to be able to serve as an UPS data server
> to other OSs, while doing the best integration with hal up2 g-p-m and
> the like.
> 
> 1rst code round (quick to be done):
> - limit support to 1 local USB UPS,
> - stick to hal battery namespace,
> - create a NUT client that listen for the local UPSs and translate
> into HAL info (project name: nut2hal),
> - upon initial USB UPS pluggin, hal (through addon-ups?):
>       - call an install package helper to install nut,
>       - call a nut helper to "autoconfigure" nut for local supervision
> (driver + upsd) based upon VID/PID, bus, ... info, or propose a GUI to
> the user. Note that I'll have a trainee engineer working on NUT
> configuration (file format, library and helper tools)
>       - (re)start nut services (this includes the nut2hal bridge),
> - further UPS connexion (ie after a disconnexion, reboot, ...) are
> handled either by the driver (auto reconnect) or the nut services.
> 
> That solution would be quick to hack:
> - we (the nut team or I) code nut2hal and create the config helper
> - David would take on addon-ups,
> - Richard and others PM GUI developers (ie KNutSettings) would take
> care of GUI...
> 
> 2nd code round:
> - consider UPS redundancy => implies multiple battery support in HAL
> - consider serial units (joint with NUT configuration projects, ie
> KNutSettings, adding some wizard)
> - consider avahi exposure for nut,
> - hal battery namespace evolution to use UPS advanced features.
> ...
> I have the NUT-NG sub project in mind, which is a major architecture
> evolution for nut, and which will allows us to go a step beyond all
> other OS's PM. For the moment, let's focus on the first round (having
> the short run user experience in mind), and let's talk about the
> cathedral after ;-)

I think this looks sorta backwards. HAL really is a low layer just above
the kernel that does all the things the kernel really should but
doesn't. In particular I'm not sure we want HAL to read from another
daemon if we can avoid it.

So I think the approach should look like this

 1. Teach HAL about serial ports; this includes functionality for
    GUI apps to probe for serial devices or select them from a list.
    Pending me sketching out how this will look. This infrastructure
    will live in HAL.

 2. Write a small GUI app for configuring serial ports; initially we
    got probably make this live in the g-p-m sources. Further down
    the road, GNOME-wise, I'd like to see g-volume-manager and g-
    power-managemer (and possibly nm-applet from NetworkManager)
    all merge into a "GNOME hardware manager" project. 

    Similarly if this can be written for KDE as well.

 3. Write addons for HAL that can handle UPS'es on serial and USB.
    This will live in the nut package. Once this is available g-p-m
    will be able to detect the UPS and enforce policy. From a desktop
    point of view this will "just work" with gnome-power-manager.

    Similarly if this can be written for KDE as well.

 4. Enhance addons with the methods such as DisableSpeaker() and
    make the necessary changes to the battery.* properties so it
    exports all the information nutd needs.

 5. Make nutd get information from HAL for USB and serial devices.
    Here you probably want a --enable-hal option in the nut package;
    with --enable-hal it installs the HAL addons and uses HAL; without
    it doesn't and consequently no addons are install into HAL. 

What do you think?

Cheers,
David