Re: formal debug levels

On Wed, 2007-10-24 at 23:45 +0800, Adrian Chadd wrote:
> Syslog type levels come to mind. Have them as bit flags, so you can do
> stuff like
>
> debug(DBG_HTTP_CLT, LVL_NOTIFY | LVL_CRITICAL) ("foo\n");
>
> That'd certainly make it easier for people writing/modifying code with
> debugging statements; they'd know what the labels mean rather than guessing
> at the numbers. :p

I agree that names are better than magic numbers, both for sections and
debug levels. However, naming constants is a minor issue, separate from
how to define the levels.

We could add bit flags for "dumps a lot of data" and perhaps "requires
administrator attention" though. That may simplify the levels
definition.

Thank you,

Alex.

> On Wed, Oct 24, 2007, Alex Rousskov wrote:
> > 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:54:11 MDT