<br><br><div><span class="gmail_quote">2005/9/16, Peter Selinger <<a href="mailto:selinger@mathstat.dal.ca">selinger@mathstat.dal.ca</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* I committed into CVS the gendb patch that I sent to the mailing list<br> on September 12. Arnaud, I hope you approve of this patch; it is<br> more reliable than the previous method in tracking the correct<br> dependencies.
</blockquote><div><br>
no, I reject this one as is. <br>
it's gcc specific to gcc, so has to be tied some way to autodetecting if we're running gcc...<br>
Moreover, there is no need for a 2nd loop. You can add this in the gendb mainloop, which make things cleaner, ie <br>
<br>
--- gendb.orig 2005-09-12 14:13:55.000000000 +0200<br>
+++ gendb 2005-09-16 09:27:05.000000000 +0200<br>
@@ -41,8 +41,8 @@<br>
EXTRAOBJ="bcmxcp_ser.o"<br>
;;<br>
esac<br>
-<br>
- echo "$i.o: main.h dstate.h serial.h $i.c $i.h" >> $MFDB<br>
+<br>
+ echo "`gcc -I../include -MG -MM \"$i.c\"`" >> $MFDB<br>
echo "$i: $i.o main.o
serial.o dstate.o ../common/state.o ../common/upsconf.o
../common/parseconf.o $EXTRAOBJ \$(LIBDEP)" >> $MFDB<br>
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<br>
done<br>
<br>
</div>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...<br>
<br>
If you make your patch conditional, and/or find equivalence for other compiler/platform, then this patch will be approved.<br>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">* This, together with some other minor recent changes on the<br> Development branch, is between the "before_PSE_3" and "after_PSE_3"
<br> tags. Arnaud: if you approve these changes, it is probably a good<br> idea to remove the extra tags at some point.</blockquote><div><br>
whenever a temp development is approved, associated tags should be removed...<br>
<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">* The regular expression matching module on the regex_branch is now<br> complete. It works great for me. Give it a try. With "-D -D", you'll see
<br> sufficient debug messages to see what's being opened and what is<br> being matched. Please let me know when I should go ahead and merge<br> these changes into the main Development branch.</blockquote><div><br>
I've not had time to dig this yet (some Debian and MGE things to deal with), but there would be some points missing:<br>
- 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"<br>
- 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.<br>
I find this interesting, but I'm not sure it has been ported...<br>
<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> This also improves the logic of device opening and reopening. The
<br> newly added "matcher" callback interface is documented in comments<br> in libhid.h and libhid.c.<br><br>My next projects are:<br><br>* clean up the newhidups code structure so that headers go in .h<br> files, and code goes in .c files. This also involves correcting
<br> attributes such as "static", "extern" etc, where necessary.<br><br>* separate the Vendor-specific code from the core newhidups driver.<br> This primarily involves replacing the various "switch (Vendor)"
<br> statements by a more general method, so that new Vendors can be<br> added more easily in the future. My plan is that each vendor module<br> supplies a set of callback functions for performing vendor-specific<br> tasks, including: - deciding whether a given device is supported by
<br> the module or not, - custom-formatting the human-readable UPS<br> description, - supplying custom Usages etc. All this goes in the<br> <vendor>-hid.c source file. The newhidups.c core driver will only<br> get a list of available vendor modules, and will delegate any
<br> vendor-specific tasks to the above-mentioned callback functions.<br>
</blockquote></div><br>
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...<br><br>
continue your good work,<br clear="all">Arnaud<br>
--
<br>Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt<br>Network UPS Tools (NUT) Project Leader - <a href="http://www.networkupstools.org/">http://www.networkupstools.org/</a><br>Debian Developer - <a href="http://people.debian.org/%7Eaquette/">
http://people.debian.org/~aquette/</a><br>OpenSource Developer - <a href="http://arnaud.quette.free.fr/">http://arnaud.quette.free.fr/</a>