[Nut-upsdev] recent and planned changes

Arnaud Quette aquette.dev at gmail.com
Fri Sep 16 08:04:40 UTC 2005


2005/9/16, Peter Selinger <selinger at mathstat.dal.ca>:
> 
> * I committed into CVS the gendb patch that I sent to the mailing list
> on September 12. Arnaud, I hope you approve of this patch; it is
> more reliable than the previous method in tracking the correct
> dependencies. 


no, I reject this one as is. 
it's gcc specific to gcc, so has to be tied some way to autodetecting if 
we're running gcc...
Moreover, there is no need for a 2nd loop. You can add this in the gendb 
mainloop, which make things cleaner, ie 

--- gendb.orig 2005-09-12 14:13:55.000000000 +0200
+++ gendb 2005-09-16 09:27:05.000000000 +0200
@@ -41,8 +41,8 @@
EXTRAOBJ="bcmxcp_ser.o"
;;
esac
-
- echo "$i.o: main.h dstate.h serial.h $i.c $i.h" >> $MFDB
+
+ echo "`gcc -I../include -MG -MM \"$i.c\"`" >> $MFDB
echo "$i: $i.o main.o serial.o dstate.o ../common/state.o 
../common/upsconf.o ../common/parseconf.o $EXTRAOBJ \$(LIBDEP)" >> $MFDB
echo " \$(CC) \$(CFLAGS) \$(LDFLAGS) -o $i $i.o main.o serial.o
dstate.o../common/state.o ../common/upsconf.o ../common/parseconf.o
$EXTRAOBJ
\$(LIBOBJ) $EXTRA" >> $MFDB
done

always keep in mind that nut runs on a lot of platform, and should continue. 
Even if gcc is a kind of standard, we can't force our users to compile nut 
with it...

If you make your patch conditional, and/or find equivalence for other 
compiler/platform, then this patch will be approved.

* This, together with some other minor recent changes on the
> Development branch, is between the "before_PSE_3" and "after_PSE_3" 
> tags. Arnaud: if you approve these changes, it is probably a good
> idea to remove the extra tags at some point.


whenever a temp development is approved, associated tags should be 
removed...


* The regular expression matching module on the regex_branch is now
> complete. It works great for me. Give it a try. With "-D -D", you'll see 
> sufficient debug messages to see what's being opened and what is
> being matched. Please let me know when I should go ahead and merge
> these changes into the main Development branch.


I've not had time to dig this yet (some Debian and MGE things to deal with), 
but there would be some points missing:
- Index. This is a param to differentiate 2 devices with exactly the same 
info (ie same VID/ PID, no serial, ...). Then you could say "the 2nd device 
with VID xxxx and PID yyyy"
- an interesting notion that was introduced by Dave Brownell (linux USB 
hacker) is the "physical path" (stable ids, which don't change unless usb 
topology morphs). For more info, search for HIDIOCGPHYS in hidups.
I find this interesting, but I'm not sure it has been ported...


This also improves the logic of device opening and reopening. The 
> newly added "matcher" callback interface is documented in comments
> in libhid.h and libhid.c.
> 
> My next projects are:
> 
> * clean up the newhidups code structure so that headers go in .h
> files, and code goes in .c files. This also involves correcting 
> attributes such as "static", "extern" etc, where necessary.
> 
> * separate the Vendor-specific code from the core newhidups driver.
> This primarily involves replacing the various "switch (Vendor)" 
> statements by a more general method, so that new Vendors can be
> added more easily in the future. My plan is that each vendor module
> supplies a set of callback functions for performing vendor-specific
> tasks, including: - deciding whether a given device is supported by 
> the module or not, - custom-formatting the human-readable UPS
> description, - supplying custom Usages etc. All this goes in the
> <vendor>-hid.c source file. The newhidups.c core driver will only
> get a list of available vendor modules, and will delegate any 
> vendor-specific tasks to the above-mentioned callback functions.
> 

I had a todo for this: put hid2nut and usages tables in external data files, 
loaded at initups/initinfo time. I'm not sure it's really interesting, on a 
sizing level, but the external usage table was part of a libhid todo. So if 
we have something portable, why not using it...

continue your good work,
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/<http://people.debian.org/%7Eaquette/>
OpenSource Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20050916/146de0c9/attachment.htm


More information about the Nut-upsdev mailing list