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

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

[...]
> 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.
As an interim solution, this would be a good solution. This would require
far less effort, since most of the changes would be in the upsdebug*
functions. Probably the only thing that would need changes if we would go
ahead with this, would be the script to generate a subdriver for
usbhid-ups.
> 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.)
This will be a little more difficult to implement. Probably the only place
where we are 'guaranteed' to have write access (if everything is
configured properly, that is) is the STATEPATH and I'm not sure that it
will be easy to tell people where the file can be found. In any case, we
should probably use a fixed name and overwrite any existing logs, so that
we don't have to deal with versioning either. This in order not to confuse
people which one to use and to prevent flooding the filesystem if they
forget to delete older versions.

Best regards, Arjen