Re: formal debug levels

On Wed, 2007-10-24 at 16:50 +1300, Amos Jeffries wrote:
> The debug sections have been formalized. But as yet there does not appear
> to be any consensus on what any given level should contain. Simply a "is
> it too much" guess.
>
> I propose that we give each level a broad category description and use
> that as a guide when deciding where to place any given debugs() detail.
>
> Just off the top of my head I have these in rough priority order:
>
> (0) serious WARNINGS and errors.
> (1) gross component start/stop info
>
> - component API calls
>
> - per- function/method start-stop info
> (for all those "xyz: Started.", "returns with V" bits)
>
> - control path info
> (whether any given code path has occured, possibly why).
>
> - SMALl local data / state data
> (variables content)
>
> - LARGE local data / state data
> (buffer content)
>
> Anything else?

An alternative approach that might simplify the level selection is to
use frequency/volume and severity/usefulness as a guide:

 0 - Should not ever happen; requires administrator action
 1 - Happens once per Squid execution or requests administrator attention
 2 - Happens once in a while, unrelated to load
 3 - Happens once per transaction
 4 - ... and dumps a lot of data (e.g., request headers)
 5 - Happens once per I/O or similar regular activity inside transaction
 6 - ... and dumps a lot of data
 7 - Happens several times per I/O or similar (e.g., parsing a token)
 8 - ... and dumps a lot of data
 9 - Happens a lot, duplicates information, or may not be very useful

> Secondly;
> since bug #2083 I have wondered about the usefulness of a macro/function
> that could be used in the section part of debugs() and caused display if
> any of N sections passed to it were at the right level.
>
> ie debugs(SECT(42,83),9, "Hi"); // display in EITHER (42 or 83) level 9

I think some kind of a tagging and context-based system would go much
further. I would not complicate the existing simple interface without a
significant benefit. I do not have a strong opinion on this though.

BTW, once native async calls are implemented, they can be used to set
the default debugging section for the entire call because each AsyncJob
will have a default debugging section. This may simplify context and
section management a lot because you would not need to do it in every
method. For example, most "entering..." and "exiting..." debugging
statements will be gone (moved to a single place).

Alex.
Received on Wed Oct 24 2007 - 09:39:37 MDT