Hi Michal, 2011/3/21 Michal Soltys <[email protected]>
> Before I start any commits. > > In patch 2/18 - > http://lists.alioth.debian.org/pipermail/nut-upsdev/2011-March/005299.html > > Two "custom" commands slipped in: ups.firmware.old and > shutdown.return.grace. In 18/18 I tried to rename them and add > remainig commands for "hackish" shutdown methods, to make them easily > callable through e.g. upscmd (for example for testing). > > Is it acceptable to add certain commands specific only to some driver > and documented in its manual page (but otherwise meaningless for the > rest of the drivers) ? Say with (in this case) a driver prefix, e.g.: > I would more be in favor of finally using the extra param of instcmd(const char *cmdname, const char *extra) and mapping these commands onto existing ones. Specific parameters would then be described in manpages. apcsmart.shutdown.grace (@nnn) > apcsmart.shutdown.grace.h (@nn) > could you please define (quite probably again, sorry) the meaning of the 2 above and shutdown.return.grace, so that I can propose something here? > apcsmart.shutdown.cs (force OB (U), then shutdown.return (S) - aka 'CS > hack') > this would give "shutdown.return cs" > apcsmart.firmware.old (V) > I'm not sure to see how useful it is. Are they really storing the previous FW version? and what is the use case? is your unit filling ups.firmware + .aux + .old? if it's the case, ups.firmware.old has to be added. otherwise, I'm not sure ups.firmware.aux would be a good option! cheers, Arnaud -- Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/
_______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
