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

[Eric S. Raymond]

Peter Selinger <selinger at mathstat.dal.ca>:
> 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.

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?

> 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.

> Nevertheless, since you are volunteering to audit the driver error
> messages, I think this would be very welcome.

Good.  I've started reading code towards this end.

> 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.

This is the kind of audit I was thinking about doing.

> 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. 

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.

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

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.

I estimate these changes will take 4 to 6 working days, with most of
that time actually spent learning the code well enough to hack it.  I
can commit that time over the next two weeks, as my other projects
happen to be at slack points for various reasons.

Beyond that, I have some ideas about making nut autoconfigure itself 
in common cases, but I need to meditate on these more before I'll 
be ready to talk about them.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>