[Nut-upsdev] megatec and some changes to cmdvartab and new-names.txt

[Arjen de Korte]

> 1) The blazer, fentonups, esupssmart, ippon, sms and mustek drivers
> are now completely covered and all of their functionality should now
> be present in megatec, and also every model supported by them should
> now be supported by megatec (with additional funcionality). So, I have
> changed "driver.list" so that all hardware supported by these drivers
> is now "megatec or <theotherdriver>".
>
> However, I think the other drivers' "ups_banner" function should be
> changed (now necessarily right now) to indicate that they are due to
> be removed sometime in the future and megatec should be used instead
> (if possible). Am I right?

I think that would be the proper way to inform people. Unfortunately many
startup scripts will just /dev/null any output we generate, so chances are
that they will never notice until the old drivers are actually removed
from the tree. If we ever do, it might be a good idea to create softlinks
to the new megatec driver instead for a couple of versions. You could then
check for argv[0] to see how the driver was started and display a similar
warning if an old driver name was used (provided there are no incompatible
changes).

> 2) I made a couple of changes to "new-names.txt" and "cmdvartab"
> (attached below), because I implemented a simple watchdog (like the
> one in the "sms" driver) and I need a new variable to display the
> watchdog status (if it is "enabled" or "disabled"). Also, I added a
> command to toggle the beeper, which I decided not to implement as a
> "beeper.on/beeper.off" pair because some models don't give any hint
> about the status of the beeeper, and the hardware command is really a
> toggle anyways (a single command). Are these changes ok?

I don't see any problems here. However I think we should encourage
developers to only use beeper.toggle if there is no way to read the beeper
status. The action of the beeper.on/off commands works irrespective of the
current beeper state, which is much more user friendly. You'll quickly
appreciate this if you happen to have a UPS within hearing distance of
your sleeping room and want to make absolutely sure that the beeper is
off. I had to neuter the beeper from a UPS for that same reason (the
clicking of the relays was already bad enough).

Regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57