On 09/04/2008, Magnus Fromreide <[EMAIL PROTECTED]> 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?



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


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.

It's a while ago now, so the details are somewhat hazy.
But the basic idea was to introduce "levels" of debug
So (for example)

         -Dmib

would only display the top-level MIB-related debug output
    (DEBUGMSG("mib", ...))

while

        -Dmib:file

would display top-level MIB-related and second-level
MIB file-related debug output
   (DEBUGMSG("mib", ...)  and DEBUGMSG("mib:file", ....))

and
        -Dmib:

would display top-level and *all* second-level  MIB-related
debug output
   (DEBUGMSG("mib", ...)  and DEBUGMSG("mib:anything", ....)
    but not  DEBUGMSG("mib:parse:bytoken",.....))


We never came to a full consensus on the exact syntax that
this should use.   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.

Dave

-------------------------------------------------------------------------
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. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to