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

[Arnaud Quette]

Hi fellows,

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

great. FYI, nut has both serial and USB support for fbsd and solaris
(10, possibly 9)

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

I'm still unsure about the right place to bridge HAL and NUT:
(you need to read "The layering" § in
http://eu1.networkupstools.org/doc/2.0.1/design.html)

- hal addon read directly from the driver (need to support multiple
UPSs, and to keep the possibility to run upsd beside for serving data
to other boxes),

- hal addon read from upsd (simplest way, and more generic/compatible,
but as you stated, it's a bit backward...)

- the nut drivers are directly hal addons . So the "< Unix domain
sockets with text-based messages >" is replaced by the hal-dbus
backend. This wouldn't be hard, as we only need to re-implement the
dstate (driver state API) using hal functions, and compiling it
conditionned on --with-hal... The only problem here (should be the
same for addon-hidups) is how to manage multiple units (=> each driver
must know where to write the data, ie battery.1.xxx)

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

I'm not sure we'll have to have specific functions, as (like what's
done in the USB drivers) we can have a lookup table between NUT and
HAL; ie
"org.fd.Device.UPS.speaker.enable" from  HAL maps onto "ups-name at host:beeper.on"

Every data, settings and commands in nut are handled through
variables, so things should be fairly easy to bridge on that side.

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

the communication pipe is a "problem" but the configuration (read
"autodectect and autoconfigure USB devs, and start the good nut
layers") is another important part. Still while keeping a serial entry
point and compatibilty with the nut clients...

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

if everything is PnP, there's already some code in rh/mandriva for
serial pnp (might help):
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/gi/tools/serial_probe/

though IMHO we should first focus on hotpluggable devs (USB).

I'm interested in your sketches, but consider (as for mine):
- both the USB and serial devices,
- initial plugging, and further connections (some devices tends to
disconnect / reconnect frequently, which is handled by the nut
drivers),
- short and long run approach for features and architectures. We
should have something releasable quickly (as in my "1rst code round").

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

that's also what I think, but remember I'm a kinda newby in the HAL world.
some of my thoughts might so refers to udevplug or things like that,
for the autodetection and configuration...

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

there are 2 approaches there too:
- the hal addon talks to 1-n drivers (same layer as NUT's upsd)
- the nut driver talks directly hal (== the nut drivers are directly
hal addons). This suppresses a layer, eliminate code redundancy, ...
I think this last approach is a good one.

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

right

> What do you think?

a good first approach.
What do you think about my feedback, and most of all about the "nut
drivers are directly hal addons" approach.

I would also like to hear from you about the "hotplug chain" (my
udevplug remark...)

Following your pong, we could lay down the various approach, and put
pros and cons on these, or go on and try whatever approach.

see you,
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/