Nut upsdev - Dec 2006 - megatec and some changes to cmdvartab and new-names.txt

I had some free time this weekend, and made some long overdue changes
to "megatec". The thing is, these changes lead to a couple of
questions that I must ask before I go on and "svn commit" them:

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?


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?

-- 
Carlos Rodrigues
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmdvartab.diff
Type: application/octet-stream
Size: 359 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20061204/00fe0d02/cmdvartab.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-names.txt.diff
Type: application/octet-stream
Size: 1199 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20061204/00fe0d02/new-names.txt.obj

> 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

On 12/4/06, Carlos Rodrigues <carlos.efr@mail.telepac.pt>
wrote:
> I had some free time this weekend, and made some long overdue changes
> to "megatec". The thing is, these changes lead to a couple of
> questions that I must ask before I go on and "svn commit" them:
[snip]

Just another question... I'm doing these changes for the trunk only.
Will there be a 2.0.5 release from the testing branch? If so, I'll
commit into it also.

-- 
Carlos Rodrigues

Carlos Rodrigues wrote:
> 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?
We also might want to add something like the following to the man pages
of the (now) obsolete drivers:

--- man/fentonups.8 (revision 609)
+++ man/fentonups.8 (working copy)
@@ -2,6 +2,9 @@
 .SH NAME
 fentonups \- Driver for Fenton Technologies (Megatec protocol) UPS
equipment
 .SH NOTE
+This driver is obsolete and has been replaced by the \fBmegatec\fR(8)
+driver. It will be removed somewhere in the near future.
+
 This man page only documents the hardware\(hyspecific features of the
 fentonups driver.  For information about the core driver, see
 \fBnutupsdrv\fR(8).

Best regards, Arjen

On 12/4/06, Arjen de Korte <nut+devel@de-korte.org>
wrote:
> Carlos Rodrigues wrote:
>
> > The problem with the symlink approach is mostly a matter of driver
> > options in "ups.conf". I'm not sure "megatec"
is fully compatible with
> > the other drivers in this respect, I'll have to check later when I
get
> > home.
>
> That was my main worry too.
A quick "grep addvar" on the obsolete drivers shows that this
can't be
done without adding some cruft to the megatec driver in order to
provide backward compatibility. I don't think there is something
significant to be gained by doing that.
> The only way to 'force' people to abandon obsolete drivers, is to
break
> existing installations and remove them from the tree. I'm not ready for
> that in the (upcoming) stable release, however for the trunk I think the
> time has come to actively discourage the use by doing just that. If we
> provide (as a service) symlinks is something we might think about.
> Personally I would like to get as much input as possible from 'the
> field' about the new megatec driver. Therefor, removing the old drivers
> from the compatibility list would be a good thing for both stable
> release and trunk as well. New installations should no longer use them,
> existing ones should be supported until at least the next major release.
[snip]
> Sure. But (like you already mentioned) we should also try to persuade
> them to switch to the megatec driver. We could gently point them to the
> new drivers (testing/stable) or more forcibly (trunk). Some of the
> drivers it is replacing have been slowly rotting in the tree for years
> and I think that (at least for the development version in the trunk)
> they could be replaced.
>
> > While both drivers remain in the tree, maybe the normal banner can be
> > accompanied by an "upslogx(LOG_WARNING..."  telling that
they're
> > obsolete. I guess that won't be redirected to /dev/null, although
> > users may not read the logs frequently enough and miss it anyways.
>
> That might be an idea, but likewise I have little hope that this is
> going to be read. Prepending a few lines in their respective man pages
> might also be a nice idea for the obsolete drivers (that won't hurt
> anyone either).
Ok. So, I'll do this (adding an upslogx to the driver, modifying the
manpage, and change the compatibility list to remove the obsolete
driver instances) for the trunk soon, and for testing in a few days or
something.

-- 
Carlos Rodrigues