Nut upsdev - Mar 2011 - apcsmart question

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.:

apcsmart.shutdown.grace (@nnn)
apcsmart.shutdown.grace.h (@nn)
apcsmart.shutdown.cs (force OB (U), then shutdown.return (S)  - aka 'CS
hack')
apcsmart.firmware.old (V)

If not - how should I approach this ?

On 11-03-21 21:50, Michal Soltys wrote:
> 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.:
>
> apcsmart.shutdown.grace (@nnn)
> apcsmart.shutdown.grace.h (@nn)
> apcsmart.shutdown.cs (force OB (U), then shutdown.return (S)  - aka 'CS
hack')
> apcsmart.firmware.old (V)
>
> If not - how should I approach this ?
>
So any recommendations ? To keep things consistent - I have to either 
revert part of 2/18 (to not have any additional custom commands), or add 
commands e.g. with driver name prefix (as above), if they have no 
standard command that could match them.

Hi Michal,

2011/3/21 Michal Soltys <soltys at ziu.info>
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110414/63368acb/attachment.htm>