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.

Agreed and yes.

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

If we were to go the bit-flag path, we should perhapse name both sections
and levels. But again that goes beyond defining the levels themselves.

>
>> 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)

I considered these 'dumps a lot of data' levels earlier and decided they
would be better going in the higher levels if there were to be included at
all.
If anyone wants to debug say a function at your level 5 or 7. They do not
exactly want to wade through the full-dump of request header buffers or
other objects to find it.

>> > 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.

I agree. BUT its a big change. once we agree on a consistent set of depth
levels that can become anything in implementation.

>> > 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.

Do you mean each of the current components would become an AsyncJob?
Great :-) I was wondering at the goal of these recent async commits

>> > 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).

That may not be such a good idea for the per-function ones.
having said that, I'm experimenting with details displayed by the HERE
macro which may replace function-specifics.

>> >
>> > Alex.

Amos
Received on Thu Oct 25 2007 - 15:01:17 MDT