On tor, 2008-04-10 at 10:26 +0100, Dave Shield wrote:
> On 09/04/2008, Magnus Fromreide wrote:
> > I would like to add some more things to the mib:
> >
> > nsDebugDefaultEnabled OBJECT-TYPE
> > SYNTAX TruthValue
> > MAX-ACCESS read-write
> > STATUS current
> > DESCRIPTION "If debug output should be generated for items
> > without any specific instructions."
> > DEFVAL { true }
> > ::= { nsConfigDebug 5 }

> How does that differ (in semantics, rather than implementation)
> from nsDebugEnabled?

The semantics of nsDebugEnabled is
false => No debug output what so ever, overrides every other setting
true => Possibly debug output subject to other settings

The semantics of nsDebugOutputAll is
false => Possibly debug output subject to other settings
true => Output ALL debug logs, overrides every other setting but
nsDebugEnabled. (Same as -DALL)

The proposed semantics of nsDebugDefaultEnabled is
false => Unless otherwise specified, output no logs
true => Unless otherwise specified, output all logs

This is conceptually equivalent to nsDebugTokenEnabled.'' (see below)
but I do not want the root value as a member of the table since it is a
bad thing if it can be removed and confusing if it can't be when it is
in the table. Additionally RFC 2578 forbids use of IMPLIED with
zero-length strings.

> > nsDebugTokenEnabled OBJECT-TYPE
> > SYNTAX TruthValue
> > MAX-ACCESS read-create
> > STATUS current
> > DESCRIPTION "If debug output should be generated for items
> > with this prefix unless a more specialized
> > match exists."
> > DEFVAL { true }
> > ::= { nsDebugTokenStatus 5 }

> (I presume you meant ::= { nsDebugTokenEntry 5 } )


> I'm not at all clear what this is meant to do?
> Are you wanting to control exact-match vs prefix debug triggers?
> If so, then the name is misleading, and the description is confusing.
> If not, then the name and description are both confusing :-)

It probably is confusing.

> If you're looking at re-working the debug handling (rather than
> just the MIB interface to it), then it might be worth looking back
> at the earlier -coders discussion on how debug tokens ought to work.

Yes I am, but only a little - I suppose you are referring to the
discussion at

What I am suggesting i a simple longest prefix match solution with the
ability to say that the prefix turns on or off matching entries, all of
this semms to be present in some form in the current debug handling,
only not working.

Under my proposal

-Dmib matches DEBUG("mib...")


-Dmib,-mib: matches DEBUG("mib...") but not DEBUG("mib:...")

The purpose of nsDebugTokenEnabled is to tell if the corresponding
prefix is an enable prefix or a disable prefix.

> It's a while ago now, so the details are somewhat hazy.
> But the basic idea was to introduce "levels" of debug
> We never came to a full consensus on the exact syntax that
> this should use.

Yes, it sounds a little fuzzy but at the same time a lot more ambitous
than my proposal.

> And getting from here to there would be a
> non-trivial problem! But that should give you an idea of how
> we were thinking last time this issue came around.

It sounds quite complex and I think the log entry matching could turn
into a noticeable cost - my proposal is not in any way as ambitious but
it is available and - I think - better than the current version that
only supports enable triggers.


This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
Net-snmp-coders mailing list