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

[Peter Selinger]

Eric S. Raymond wrote:
> 
> 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.

Yes, to this list! Small changes to many files are no problem; the
things you are about to change are unlikely to have been touched
recently, so there should be few if any potential conflicts.
 
> 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?

No, Russell is no longer involved in NUT. The project leader is Arnaud
Quette. There are a number of us that are "senior lieutenants" (I like
the title). I am not in charge of giving SVN access, but from what I
have observed since I have been here, it seems that the de facto
policy is that such access is given by invitation, usually after a
person has submitted a few quality patches.

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

Seems reasonable to me.

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

Yes, but keep in mind that people might be starting their drivers
without "upsdrvctl" - especially during the initial testing, when
unexpected errors are most likely to occur. So I think it's better to
keep the error messages in the drivers.

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

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

No, I think this should be handled centrally, i.e., by modifying
config.h and/or the default CFLAGS -D options. There is already a
preprocessor macro UPS_VERSION that all the drivers (should) use. (A
better name would be NUT_VERSION, but never mind). 
 
> 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.

Sounds great. -- Peter