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

[Arjen de Korte]

>> Great, a volunteer! Even without too much hell raising, I am sure any
>> patch you submit will be appreciated.
> Patches should be mailed to this list?  Um, and actually we're
> probably talking about lots of small changes scattered over many
> files.  It would probably be easier on everybody if I just got SVN
> commit access.  I do know how to play nice with it.

In order to save everyones time, I think that will be the most sensible
thing to do.

> You've been responding as though you are now the de facto project lead, or
> at least a very senior lieutenant.  Is Russell Krol still active?

Not really, Arnaud Quette took over his command about a year ago (if
memory serves).

>> 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.
> I wasn't singling out Alex, and I apologize if my remarks were taken
> personally by anyone.  I took your remarks to imply that most drivers
> don't have such messages, and that it's not project policy to require
> them.  That was the "disease" I was muttering about.

I beg to differ here. Most drivers play nice and use fatalx() or
fatal_with_errno() to bail out if something really bad happens. We've had
these commands for quite a number of years already and many drivers use
them. The ones that don't, are mostly the older ones (before these we're
made) and/or from the newer developers that are not yet familiarized with
all these 'standard' functions. Developers must not use exit() at all. The
docs/developers.txt should probably mandate the use of these over calling
exit() directly, in order to guarantee that the error messages are
actually visible somewhere (even if the driver has been backgrounded
already). I hereby volunteer to replace all instances of exit() by
appropriate calls to fatalx() or fatal_with_errno() in the existing
drivers.

[...]

> Noted.   Here's the work plan I had in mind:
>
> First, read all the drivers.  See if I can ID a handful of the most
> common exit-failure reasons.  Split up EXIT_FAILURE into several
> different codes, including codes for the most common failure causes
> and an 'exit for unspecified reason' catch-all numerically equal to
> the present EXIT_FAILURE.  (EXIT_CANTFIND would be the case I tripped
> over.)
>
> Teach upsdrvctl to emit an appropriate message on each of the standard
> codes.
> My reason for wanting to do it there rather than in individual drivers is
> that
> later we might want to modify the "standard" error messages and handling
> --
> and that will be easier if they live in one place in upsdrvctrl as apposed
> to having copies in every driver.

I like this idea, although the number of possible replies is probably
limited to not finding the UPS. Most other frequent driver problems (like
not being able to write to the STATEPATH or permissions problems for the
serial or USB port used) are handled by code common for all drivers.

> (Of course, individual drivers could still emit their own failure
> messages; they'd issue just before the generic ones.)

What would probably be a neat way to solve this, is to add an additional
parameter to fatalx() and fatal_with_errno() to allow setting an exit
code. So instead of calling

    fatalx("No suitable UPS for this driver found");

one should call

    fatalx(EXIT_CANTFIND, "No suitable UPS for this driver found");

Of course this will require massive amount of small changes to pretty much
all sources (including non-drivers), but has the advantage that many
drivers already use their own descriptive messages which would be printed
right before the call to exit() by fatalx() and fatal_with_errno().

> As a bonus, and since I'm going to have to walk through all the drivers
> anyway, I'd implement another feature I previously suggested -- SVN
> revision in the driver banner announcements.

That would be very useful indeed. This is something we badly need, in
order to prevent confusion when people mention that they tried 'the latest
version from SVN'.

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