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
Adrian
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.
>
--
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level bandwidth-capped VPSes available in WA -
