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

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@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/

> 2006/3/10, David Zeuthen <david@fubar.dk>:
> > 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.
Even if it is against spirit of HAL, why not define unified format for
undetectable devices? I guess it will not break the well-defined view
and not only serial UPSes can benefit from it:
- Unable or dangerous to detect non-PnP ISA cards (sound,...).
- Special and obscure serial devices.
- Obscure and old parallel devices (newer support BiTronics detection).
- Historic displays or displays connected to historic video cards.
- Maybe UPS power cabling.
- Maybe devices connected to I2C buses.

I can imagine that we put undetectable device descriptor (that can come
from manufacturer in future) somewhere into say
/usr/share/hal/devices/foo.dev, then specify in some configuration file,
that /etc/hal/extra-devices.conf, that will define, that foo.dev is
connected to /dev/ttyS0. Then the future standard device autoscanner
will skip /dev/ttyS0 when searching for modems.

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SuSE CR, s. r. o.                             e-mail: sbrabec@suse.cz
Drahobejlova 27                               tel: +420 296 542 382
190 00 Praha 9                                fax: +420 296 542 374
Czech Republic                                http://www.suse.cz/

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