[Nut-upsdev] Re: Status of the PSE NUT patches (was: NUT patches)

Arnaud Quette aquette.dev at gmail.com
Mon Sep 12 12:40:01 UTC 2005


[I'm switching my dev address to @gmail.com instead of @mgeups...
please, update your bookmark]
 
Peter Selinger wrote:
> > Arnaud Quette wrote:
> >
> > Here is the status of PSE (Peter Selinger) NUT patches
> > for newhidups (hidparser, apc support, ...).
> >
> > - nut-cvs-patch-REOPEN-2005-08-24:
> > approved and applied on Development tree
> > Notes: - avoid cpp style comment
> >             - I don't see the difference as we return when
> >       the driver unbind has been done. You'll only get
> >       again the mfr,model and serial strings! Or maybe
> >       that was previous to my change to it (move after
> >       unbind)...
> 
> You are right; when I made this change, the order of the operations
> was different. Still, I think there are some benefits to repeating all
> the "open" steps when "reopening" a device; for example, if a serial
> number is found, but is not equal to that of the previous device, we
> can search for the device with the correct serial number. This should
> be reasonably accurate for ensuring that the same device is reopened,
> in case someone has more than one device attached.

right. Note that I've an evolution/todo for newhidups with the mfr,prod,serial
params to get the right unit when there are multiple. These can
be used for the same purpose... (part of the switch to libhid)

> > - nut-cvs-patch-DEP-2005-08-24:
> > not applied. I'd like to have something more generic, along
> > with the gendb system, that will declare some base deps
> > (ie "main.h dstate.h serial.h" for serial drivers), and a @.h
> > one (need to have a .h for every driver). Then, there will
> > be the special cases (usb, snmp, ... drivers)
> 
> A permanent solution would be very nice. In the meantime, the complete
> absence of useful dependencies is annoying, especially as they can be
> generated automatically.

yep, that's also a long standing (low prio) point of my todo list.

ok, I've prioritized my work on this subject. So we currently have 3 categories
(detailled audit attached):
1) standard deps (serial with ${drv}.h (ie "main.h dstate.h serial.h
mge-shut.h")
Added to gendb as generic (ie with HDEPS and EXTRAHDEPS) in the
current CVS Development branch

2) standard deps (serial without ${drv}.h (ie "main.h dstate.h serial.h")
I have added a ${drv}.h for each of these drivers, with the same
header as the .c but with the DRV_VERSION, and added to gendb as
generic (same as in the above (1)).

3) specific deps (ie dummy-ups, newhidups, energizerups, ...)
These specific case will remain handled in Makefile.in, at least for
the moment. These might one day be added to gendb too...

This way, we don't forget new drivers (ie gamatronic was missing)
I've just commited it in the CVS Dev...

> > > * ups.test.panel / Panel test / 0
> > >
> >   > My APC UPS has a "panel test" variable, which consists of a single
> >   > R/W bit. .....
> >
> >   I've not kept this one. We'll have to speak / audit a bit
> >   more before applying...
> 
> That variable is useless anyway. I think it should probably be removed
> permanently, until some other UPS model comes along and needs it.

ok, so it's commented for the recall...

Arnaud
---
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
OpenSource Developer - http://arnaud.quette.free.fr/
Debian Developer - http://people.debian.org/~aquette/
... and much more ...



More information about the Nut-upsdev mailing list