> 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
