On Sat, Dec 11, 2010 at 09:40:17PM +0000, Roddy Pratt wrote:

If a NULL tag is passed to smiInit the config file isn't read. I had to read through the init code before I realised what was going on.

...

If tag is not NULL, the global configuration file and (on UNIX systems) a

user configuration file are read implicitly,

Yes, it's documented, but it doesn't feel like 'natural' behaviour. Why would you not want the init file called in this case.

Since this is the only way to turn off reading init files and thus have complete control over things? It is not clear to me whether you have a problem with the semantics of smiInit() or its documentation or both. Perhaps you can send a patch so I can better understand what you think is not 'natural'.

/js

Hi Juergen,

It's always easy to be critical of existing code with hindsight, and it wasn't my intention to do that. Apologies if that's what it seemed.

The one parameter to smiInit does two functions: It's a tag that controls which of the MIBS specified in the configuration file are loaded - and it also determines if the default configuration file is read or ignored. This 'overloading' of one parameter with two functions was the cause of my confusion.

I have two independent simple "patches" which might help, without modifying/extending the library interface, or breaking current code.

In smi.h, add a #define

#define SMI_LOAD_DEFAULT "__Default" // Use this with smiInit to load the default configuration file

Users can then call smiInit(SMI_LOAD_DEFAULT) rather than smiInit("foo"). More readable, and should help make the intention clear. The actual code for smiInit() remains unchanged.

My second 'patch' is to the code example on the website: http://www.ibr.cs.tu-bs.de/projects/libsmi/example.html?lang=de

As you can see, it calls smiInit(NULL), so won't load any MIBs. This example is probably why I struggled in the first place. I believe this should call

smiInit("foo"); // force loading of default config // or, if you like the previous suggestion, smiInit(SMI_LOAD_DEFAULT)

Regards, and thankyou for a great library.

Roddy Pratt Rascular Technology Ltd.

The definition of SMI_LOAD_DEFAULT does not make much sense. If at all, it should be defined to be "" but even then you really like to pass the name of your application.

Understood. Life is never as simple as it seems.

I still think the code example on the website must be changed to either smiInit("") or smiInit("example") - because with smiInit(NULL) the example will never output anything useful.

Roddy Pratt Technical Director

Rascular Technology Ltd. The Oak House, Whitcott Keysett, Craven Arms, UK. SY7 8QE Tel: +44 1588 640971 Fax: +44 8432161733

www.rascular.com

On 14 December 2010 15:43, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote:

On Tue, Dec 14, 2010 at 02:04:22PM +0000, Roddy Pratt wrote:

...

The one parameter to smiInit does two functions: It's a tag that controls which of the MIBS specified in the configuration file are loaded - and it also determines if the default configuration file is read or ignored.

This

...

'overloading' of one parameter with two functions was the cause of my confusion.

I have two independent simple "patches" which might help, without modifying/extending the library interface, or breaking current code.

In smi.h, add a #define

#define SMI_LOAD_DEFAULT "__Default"   // Use this with smiInit to

load

...

the default configuration file

Users can then call smiInit(SMI_LOAD_DEFAULT) rather than smiInit("foo"). More readable, and should help make the intention clear. The actual code

for

...

smiInit() remains unchanged.

Nope, this would be wrong:

smiInit(NULL) - no configuration file is loaded at all smiInit("foo") - all global configuration statements and all configuration statements tagged "foo:" are loaded smiInit("foo:bar") - all global configuration statements and all configuration statements tagged "foo:" are loaded into the MIB module dataset "bar".

The definition of SMI_LOAD_DEFAULT does not make much sense. If at all, it should be defined to be "" but even then you really like to pass the name of your application.

...

My second 'patch' is to the code example on the website: http://www.ibr.cs.tu-bs.de/projects/libsmi/example.html?lang=de

As you can see, it calls smiInit(NULL), so won't load any MIBs. This

example

...

is probably why I struggled in the first place. I believe this should

call

...

smiInit("foo"); // force loading of default config // or, if you like the previous suggestion, smiInit(SMI_LOAD_DEFAULT)

As explained above, "foo" causes the default and the "foo" config to be loaded. Here is an attempt to improve the documentation:

The smiInit() function should be the first SMI function called in an application. It initializes internal structures. If tag is not NULL, the global configuration file and (on UNIX systems) a user configuration file are read implicitly, if existent. All global statements and those statements with a tag (a "tag:" prefix) that matches the tag argument are executed (see also CONFIGURATION FILES below). If tag is NULL, no configuration files are read, leaving full control to the application. smiInit() returns zero on success, or otherwise a negative value.

The smiInit() function can also be used to support multiple different sets of loaded MIB modules. In this case, the tag argument consists of the tag followed by a colon and a name to differentiate the loaded MIB module data sets. Any library function call subsequent to an smiInit("tag:dataset") call is using the most recently selected data set.

/js

-- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/

Ok, smidiff clarifies the use of smiInit more concisely, never had occasion to use it, thanks for the pointer to that program. The usage is less muddy with that example, so smiInit - according to that example can be called more than once.

smiInit, can be called multiple times, for each individual parse tree as needed and tag:dataset, which basically maintains an internal reference or 'handle' as the code infers.

Having said that, in regards to smidiff, smiInit, is called more than 2 times in the same code, i.e. one has 'oldtag' and 'newtag', which also provokes other questions...

So every time smiInit is called, it parses, the MIB, in the case of smidiff. So, if one called 'smiInit("myMib") and 'smiInit("otherMib")', smiInit simply parses that mib. Which seems to be the case, in smidiff.

To clarify a bit, of the questions I am asking, in the past when I used libsmi, I loaded all of the mibs (SMI) in the smirc, one time, at startup, as it was my thought, that I only wanted to parse what I was using, one time, at start up, since if one loaded many times throughout the program, from an efficiency standpoint, one would induce many 'parse' actions, which, in my train of thought, at the time was unnecessary overhead for the project I used it in. Of course the trade off would be a larger memory footprint while running, since everything loaded for parsing, would be maintained in memory, for the duration of the program.

So since memory was plentiful, I did not think the less efficient method of loading and unloading throughout the life of the program, was necessarily a trade off I wanted in my implementations. I/O (reading/writing of files/sockets) is more expensive in terms of efficiency, than parsing every thing one time at startup. So, I elected to go with one time parsing.

As far as a 'problem' there really is none, as I have used libsmi successfully in a few projects as it is. It works. But a keen understanding of how the original authors intended it to be used is very much of benefit to further leverage it.

To further elaborate, the reason I asked for clarification is basically for the following reasons:

1) There was mention of a C++ wrapper, which I have developed, using the man pages of the C functionality, it is not ready for prime time (yet), as I have yet to test all of it's functionality against the C functionality intended. I.e. when I use a library, in general, I implement functions as they are needed against their prescribed usage. Having said that, when implementing a C++ wrapper, it is important that the C++ code applies the underlying C code in the context it was intended. So testing and understanding of each of the C functions and their intended use is paramount (IMO). The intention is not to change how libsmi works, but provide a C++ layer that works on top of it.

2) Thread safe... In object oriented land, I do use threads, a lot. So basically, part of the wrapper, is to address this, without having to change code in libsmi. The intent is not necessarily to provoke the original authors to change all of the C code to be thread safe, but to add some level of thread safe operation in the C++ layer...

That is the intent of my questioning... As a side note, doing the C++ whether it is chosen by the author(s) to implement, there is a small name space problem with the existing implementation...

The compiler(s) used, are gcc/g++, when compiling using g++ and including the smi.h, I encountered the following:

1) There are references in a few lines of code, that refer to 'extern SmiClass' and take pointers to 'char *class', in C++ 'class' is a reserved word, so these references were changed from 'class' to 'clazz' so the C++ compiler was happy, it did not change the functionality of the original underlying C functions. (it doesn't care anyway, all it is really looking for is a character pointer).

If it is desired, I will supply a diff with these ever so minor changes. Personally, I would consider this a patch, be it minor, but it also makes the C++ compiler happy.

So, what is to be gained by wrapping in C++? Well, I would submit the following for consideration...

1) libsmi works, at C code level (I say this, simply because, IMO, no code is perfect, not mine, nor MicroSloths', or whoevers'), so it is VERY important to understand the author's mindset. The benefit is that any useful code that addresses an issue, as in the case of libsmi, is beneficial - I use it, it works.

2) A well debugged C++ wrapper that deals with these issues, will require less code to be written, in my 20+ years of programming, the one thing I have found that is true, the more lines you write, the more error prone it becomes, so less implementation code = less implementation errors. That is not to say that a wrapper is simple in nature, but only to say that it, in and of itself addresses an issue I believe to be important, in the very least, at the level I intend to leverage libsmi.

Being clever, is an exercise of implementation of functions, having said that, being too clever, is a function of ego, not practicality. What code I write, my end goal is to have VERY low maintenance code, that gets results, as efficiently as possible.

On 12/11/2010 10:01 AM, Juergen Schoenwaelder wrote:

On Sat, Dec 11, 2010 at 09:24:18AM -0600, Mark Martin wrote:

...

I have used libsmi for a couple of projects, having said that, the one thing I have discovered in regards to smiInit (this is proven with the sample progam, smiInit takes an argument, or NULL, using NULL, it will not dump the OID tree, except for the first node, then nothing else follows... except the remaining numbers. However, if you put something (doesn't matter what) as a char * argument, the tree parse works. I have looked at the manual page many times, and even looked at the 'C' code for smiInit, and I am not sure of the full functionality of the argument, other than it adds a 'handle' in the init function, all the the man page says is 'tag:dataset' I am not sure what this means in the context it is implemented.

Can someone provide more insight, as to how and why someone would used this, by a more practical explanation?

I can pass "x", and the parse works, no "x:yyy", so I am not sure what this parameter would be used for other than it actually parsing the mib tree.

Here is the man page text:

The smiInit() function should be the first SMI function  called  in  an
application.  It  initializes  its  internal  structures. If tag is not
NULL, the global configuration file and (on UNIX systems) a  user  con‐
figuration file are read implicitly, if existent. All global statements
and those statements with a tag (a ‘‘tag: ’’ prefix) that  matches  the
tag argument are executed.  (see also CONFIGURATION FILES below).  smi‐
Init() returns zero on success, or otherwise a negative value.

The smiInit() function can also be used to support multiple sets of MIB
data.  In this case, the tag argument may be prepended by a colon and a
name to differentiate the data sets. Any library function  call  subse‐
quent  to  an  smiInit("tag:dataset")  call is using the specified data
set.

Perhaps it is not the best text. But then, from your description, it is also difficult to infer what your specific problem is. In most circumstances, you simply use smiInit(NULL) or smiInit("myfancyapp"). The "tag:dataset" notation is only relevant if your program needs to maintain multiple independent parse trees, like for example smidiff.

/js

As a 'brief' summary and follow up of previous dissertation, I think the following would be a good modification for the existing C++ wrapper, based on the context of smidiff, currently based on my usage, I considered smiInit to be global in scope, calling it once per program, having said that I it makes more since to encapsulate it in it's own object (and supporting object function), since it can be called multiple times.

On 12/11/2010 10:01 AM, Juergen Schoenwaelder wrote:

On Sat, Dec 11, 2010 at 09:24:18AM -0600, Mark Martin wrote:

...

I have used libsmi for a couple of projects, having said that, the one thing I have discovered in regards to smiInit (this is proven with the sample progam, smiInit takes an argument, or NULL, using NULL, it will not dump the OID tree, except for the first node, then nothing else follows... except the remaining numbers. However, if you put something (doesn't matter what) as a char * argument, the tree parse works. I have looked at the manual page many times, and even looked at the 'C' code for smiInit, and I am not sure of the full functionality of the argument, other than it adds a 'handle' in the init function, all the the man page says is 'tag:dataset' I am not sure what this means in the context it is implemented.

Can someone provide more insight, as to how and why someone would used this, by a more practical explanation?

I can pass "x", and the parse works, no "x:yyy", so I am not sure what this parameter would be used for other than it actually parsing the mib tree.

Here is the man page text:

The smiInit() function should be the first SMI function  called  in  an
application.  It  initializes  its  internal  structures. If tag is not
NULL, the global configuration file and (on UNIX systems) a  user  con‐
figuration file are read implicitly, if existent. All global statements
and those statements with a tag (a ‘‘tag: ’’ prefix) that  matches  the
tag argument are executed.  (see also CONFIGURATION FILES below).  smi‐
Init() returns zero on success, or otherwise a negative value.

The smiInit() function can also be used to support multiple sets of MIB
data.  In this case, the tag argument may be prepended by a colon and a
name to differentiate the data sets. Any library function  call  subse‐
quent  to  an  smiInit("tag:dataset")  call is using the specified data
set.

Perhaps it is not the best text. But then, from your description, it is also difficult to infer what your specific problem is. In most circumstances, you simply use smiInit(NULL) or smiInit("myfancyapp"). The "tag:dataset" notation is only relevant if your program needs to maintain multiple independent parse trees, like for example smidiff.

/js