[Nut-upsdev] [Nut-upsuser] Belkin F6C1100-UNV

[Peter Selinger]

[I am moving this thread to the developer's list]

Eric S. Raymond wrote:
> 
> Peter Selinger <selinger at mathstat.dal.ca>:
> > Well, the actual driver should print some message at debug level 0
> > before croaking. Like "I didn't recognize this UPS; please try
> > specifying the vendorid and/or subdriver parameters". I don't think it
> > can be handled by upsdrvctl itself, as it can't know why some
> > particular driver fails. The bad news is that it has to be done in
> > each driver separately.
> > 
> > Alexander, can you do that?
> > 
> > Some other drivers, like newhidups, already do such a thing; see e.g. 
> > drivers/belkin-hid.c:404-408.
> 
> More generally than that: no driver should *ever* croak and die
> without emitting an informative message to standard error.  That's
> what standard error is *for*!
> 
> I think I'm going to join the dev list and raise a little hell over there.
> You're talking about fixing one symptom, but there's an underlying 
> disease here that needs to be cured.

Great, a volunteer! Even without too much hell raising, I am sure any
patch you submit will be appreciated.

For the record, the megatec_usb is a very new and experimental
driver. It has not yet been released as part of any NUT release; it
only exists in SVN at this time. It is being actively developed and
Alexander has been doing a terrific job straightening out this
driver. 

I think a few kinks in a driver that is still under development and
has not been released does not qualify as a "disease". You are being a
bit too harsh here. 

Nevertheless, since you are volunteering to audit the driver error
messages, I think this would be very welcome. Start by looking at
docs/new-drivers.txt, which defines how drivers are supposed to
behave. You will notice that there are two initialization functions:
upsdrv_initups and upsdrv_initinfo. In the typical case for NUT
drivers, the UPS is connected on a serial port. Here upsdrv_initups is
supposed to set up the physical link, and upsdrv_initinfo is supposed
to probe the UPS. The file documents that upsdrv_initinfo should
display an error when it fails.

USB drivers are somewhat different, as usually any potential failure
already happens in upsdrv_initups(). So docs/new-drivers.txt probably
should be updated to ensure that the driver also displays an
appropriate error in this case, and the (few) drivers to which this
applies should be checked. Most drivers already do this.

Perhaps another area for your scrutiny would be to ensure that the
debug levels of messages are used consistently, at least for levels 0
and 1. A failing driver should clearly print an appropriate message,
even if -D has not been selected. I don't think this is done
consistently. If you are motivated to look into this, by all means
please do. 

-- Peter