> Hi I'm interested in configuring scotty to NOT autoload MIBS. The reason for
> this is that for agent testing it is desirable to only use the MIB items
> defined for a particular device.
> I have included a "set tnm(mibs) {}" in my site/init.tcl file before
> I perform any mib access calls BUT the default MIBs are already loaded!!
> Having checked the sources I see that these are explicitly loaded
> in tnmMibTcl.c
> WHY HAS THE FLEXIBILITY OF USING THE "init.tcl" FILE BEEN COMPROMISED?????
(Uppercase in email usually means shouting - is it necessary to shout
on this list? You are using some freely available software so you
should bundle your energy and contribute code instead of shouting at
the authors.)
> What I would suggest is a better way of doing this is to have these
> default *.tc *.smi *.mib files specified in the tnm(mibs) variable,
> Thus giving the user the option to override these if required.
There are some trade-offs here. First, I would like scotty to be smart
and to know about basic SMI/TC definitions. So a user can just write
`mib load rfc1757.mib" and he gets the RMON MIB together with a useful
set of SMI/TC and default MIB definitions. This makes sure that for
example DisplayStrings are handled correctly in nearly 100% of all
cases.
Putting the core set of MIB definitions into the tnm(mibs) variable
makes things a bit more complex to use because the user now has to
provide the set of MIBs that his or her script needs. The typical user
will either load too many definitions (which wastes some memory) or
he/she will complain because e.g. DisplayStrings are returned in
primitive OCTET STRING format. So I decided that a set of build-in
default definitions makes sense.
I agree that hard-coding these names in the C code was a silly thing
to do - at least some people might be happy to not use the standard
SMI/TC definitions.
Of course, the real problem is that scotty can't resolve the IMPORT
statements included in the MIB modules. The problem here is basically
the mapping of module names to file names. The mosy compiler solves
this problem by using the module name as the file name. This approach
is problematic if your target platform does not support arbitrary file
names. A more complex solution would be to hack the parser to maintain
a MIB module to file name index file, much the same way the parser
writes compressed idy files. This index could later be used to locate
MIB modules while processing IMPORT statements.
I decided to create a short term solution by defining a new tnm array
element: tnm(mibs:core) now holds the set of core MIB definitions. It
contains the list of MIB files currently hard coded in the C code.
Juergen