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

[Arnaud Quette]

Hi Peter,

2006/8/3, Peter Selinger <selinger at mathstat.dal.ca>:
> Hi Arnaud,
>
> > 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)
>
> Basically, I have no idea what HAL means or what it is good for

Hardware Abstraction layer. look at the ref [1] I've given for more info.
It's really interesting on the Common Power Management ground...
It will allow to share a common set of power management policies and
tools (graphical, daemon, applets) for both the laptop/ACPI and
UPS/NUT-HAL on many systems (linux, *BSD, solaris, ...) while keeping
the same NUT code base, and the client layer compat.

> (wasn't that the name of the computer in "2001: A Space Odyssey"?).

the IBM (1 letter swap gives HAL) trick. unrelated ;-)

> However, I think that newhidups can handle multiple identical UPS's.

of course, it can now.

> The user can make a configuration for each device via the vendor,
> product, serial, bus mechanism; identical devices can be identified by
> serial number and bus. Also, it is not mandatory to use "auto" as the
> port value; since the port value is ignored, the user should be able
> to use "auto1", "auto2", or any other names.

in fact, the current problem is that I had no idea on how to get the
needed regex to match the right dev. So I've simply hard coded "auto"
for the dev path while waiting to have more insight.
There is no configuration. Simply some rules (the 20-...fdi file) to
tell HAL that this USB dev is handled by this addon (nut driver).
Automagic things sometimes make the programmer's life harder, but the
user's life easier, and that's the whole point.

Meanwhile, Dave (HAL PL) gave some good pointers for the bus and dev
ID. And I'll submit another one, that need an libusb extension, to be
able to open a dev from a physical path (ie /dev/bus/usb/XXX/YYY on
linux).

so that's not a big case. The big one, as told, will be the realiable
poweroff handling.

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/