Re: formal debug levels

> On Fri, 2007-10-26 at 10:30 +1300, Amos Jeffries wrote:
>> > On Wed, 2007-10-24 at 09:53 -0600, Alex Rousskov wrote:
>> >> 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.
>> >
>> > I agree to a point. Bitmasks have advantages (finer-grained filtering)
>> > and disadvantages (less useable levels). The biggest challenge is IMO
>> > managing to be consistent throughout the code-base.
>> >
>>
>> And THAT dear folks is why the 'grouped' levels I proposed. Rather than
>> the usage-size Alex proposed.
>>
>> People in general are far better at classifying things into groups than
>> estimating sizes. Particularly when there is no prior knowledge of the
>> popularity of other non-related things (such as future indirect usage
>> within a loop) which may impact a size calculation.
>
> The levels I proposed are not based on sizes but on expected frequency
> and importance, which is usually well-known.

(By size above I meant the relative size of data sent to the log. That is
a function of frequency.)

As I see it, that is what the current levels were supposed to be.
Which easily leads to the current a state where everything that gets
debugged is considered important (it was when the line was added) and
ALL,2 is enormous with about half of the content from ALL,9 and all the
levels in between each have to be tested empirically to see which is going
to show the details wanted.
Only developers with a deep knowledge of squid event frequencies have a
chance of getting the estimate right, and even then mistakes can be made
(try debugging storage+IO events at a 'simple' level 3 for example).

> Data dumping should
> probably be a flag that does not affect the level (if we need that
> control at all).

We agree on that.
I am thinking of using a high bit of the level int, and a "+" in config
making the squid.conf BNF opt := ( S | "ALL" ) "," L ["+"] [ " " opt]

Amos
Received on Mon Oct 29 2007 - 18:34:59 MDT