Carlos Rodrigues
2006-Dec-04 04:01 UTC
[Nut-upsdev] 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
Arjen de Korte
2006-Dec-04 12:15 UTC
[Nut-upsdev] megatec and some changes to cmdvartab and new-names.txt
> 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
Carlos Rodrigues
2006-Dec-04 16:40 UTC
[Nut-upsdev] Re: megatec and some changes to cmdvartab and new-names.txt
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
Arjen de Korte
2006-Dec-04 21:40 UTC
[Nut-upsdev] megatec and some changes to cmdvartab and new-names.txt
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
Carlos Rodrigues
2006-Dec-04 21:50 UTC
[Nut-upsdev] megatec and some changes to cmdvartab and new-names.txt
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
Seemingly Similar Threads
- New UPS protocol choice - Dynamix
- REGRESSION: New "megatec" driver does't work for UPS that was managed by old fentonups driver
- energizerups and bestups -> megatec?
- energizerups and bestups -> megatec?
- Voltage override in megatec and megatec-over-usb [was: Re: nut-2.0.5 megatec + Online Xanto]