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

Wed May 24 21:42:58 UTC 2006

Hi David and fellows,

I'm reviving this important thread about a common power management.

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.

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

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.

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

> ...
> I'm not sure HAL should know anything about networked devices... On the
> other hand it does make some sense. But it's a slippery slope.. and how
> would upsd-network-hald-addon even know which UPS's to monitor? Again,
> it can't rely on a configuration file!

I well understand the "hotplug" notion behind hal, and I've taken it
into account in my proposal.

> Not to flame, but I think it would make sense to take the user
> experience into perspective before discussing technical issues.

this has always been my aim, and I'm pleased to hear it ;-)

> How about this instead
>
>  1. gnome-power-manager to include functionality for discovering
>     networked UPS devices.

we first need to clarify a point: networked UPS will only be NUT ones
(nut's upsd). All other network UPSs are handled by nut drivers (ie
SNMP).

> I don't really know how this works but
>     I expect some auth is necessary. Hence, you really want to
>     run this in the desktop session as asking users to edit
>     configuration files is just wrong. If the UPS is discoverable
>     using Zeroconf/Bonjour etc. maybe g-p-m should use Avahi
>     to discover them and prompt the user for auth when it finds
>     an UPS.

I'll have to give a look at avahi, in a nut perspective as it's part a
another sub project of mine (Dynamic UPS Configuration Protocol)

>  2. Maybe g-p-m should provide UI to share an UPS on the network
>     so other g-p-m instances can monitor it. For this we could
>     indeed use Avahi to publish the information. Then stuff would
>     just work :-) ... Again, I don't know much about how this works,
>     I'm thinking out loud :-)

same as 1.

>  3. upsmon to use an interface in g-p-m to get the information
>     about the UPS and provides interface for graphical old
>     fashioned NUT clients. This means g-p-m will have to export
>     some of the info HAL already exports but I think this is
>     cleaner as I don't really want HAL to know about networked
>     UPS's.
>

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

> We could make UPS support rock with gnome-power-manager [1].

and others too (I'm more k oriented... noobody's perfect ;-)

I hope I will this time receive good feedback,
Arnaud
-- 
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/