[Nut-upsdev] standardizing debug log levels [was: passing nut_debug_level from upsdrvctl to drivers]

[Charles Lepple]

On Jan 27, 2008 11:07 AM, Arjen de Korte <nut+devel at de-korte.org> wrote:
>
> >> I also think we should not encourage people to post debug output before
> >> consultation with a developer. Most of the time, providing useful debug
> >> output requires more than just running the driver with an arbitrary
> >> number of -D flags anyway.
> > Well, the Tripp Lite units have had such buggy firmware in general
> > that I am tempted to just print out some debugging instructions in the
> > driver output, if we run across certain models.
>
> That might be a good idea. :-)
>
> The reason for not doing this in 'upsdrvctl' (I have been thinking about
> something similar before) is that there currently is no standard about how
> much debug information is printed at the different debug levels. The
> verbosity of some drivers prevents extracting useful information above
> debug level three, while others need to be run with a debug level of at
> least five before they start indicating something useful. This probably
> need standardization of some sort, but the amount of work involved
> prevented me from starting this.

I agree that this would be useful, but you're right - it's a big task.

Another possibility is to tag the debug output in such a way that we
can use tools like grep or awk to filter debug messages. Example
output from libhid (Martin Krafft wrote this part):

  TRACE: hid_init(): initialising USB subsystem...
  TRACE: hid_init(): scanning for USB busses...
  TRACE: hid_init(): scanning for USB devices...
 NOTICE: hid_init(): successfully initialised HID library.

The "trace" messages are one level lower than "notice", and are
controlled by a variable similar to nut_debug_level. If we wanted to,
we could print the debug level itself, and filter based on that after
the fact.

Maybe the -D flags could control what gets printed to the console, and
if any -D flags are used, a debug log gets written. (We could
standardize the filename to include the driver name and date/time, as
well.)

Getting back to your original idea, we could ask a few users to run
this on the drivers they normally use, and that could give us an idea
of the typical amounts of debug information printed at each level
(without having to possess the equipment itself).

Just brainstorming...

-- 
- Charles Lepple