nebmods API

[Andreas Ericsson]

So...

I've taken up hacking on a redundancy/loadbalancing module (old news) 
and it's starting to come together quite nicely. Unfortunately, I've run 
into a couple of very irritating problems which had to be worked around 
in sometimes less than optimal ways.

1) There's no simple way to #include everything one needs to make full 
use of a loadable API or select parts of it that are necessary. 
Prototypes are scattered wide through the header files, each .c brings 
in its own extern'al ones, and no global vars are
2) Object config filenames are thrown away after they are parsed inside 
the function that calls the parser, so they never make it global.
3) (I've posted about this before) Most string variables are stored in 
flexible-length pointers, making it seriously difficult to handle as 
network data. It also adds a necessity for deep memory management and an 
unseemly amount of malloc()'s and free()'s. It also makes it completely 
impossible to store objects.cache in a binary file for ultrafast parsing 
by the CGI's.
4) There is no way for modules to help Nagios handle more config options 
the way Apache does.

These problems require "design intervention" ;) to a greater or lesser 
degree so I won't be starting on hacking patches until I've heard from 
Ethan on this.

Solving #1 would actually make the package nagios-devel useful. The 
manpage nagios-neb(3) should ofcourse see the light of day, if only with 
a list of prototypes, exported functions and available macros. In 
reality, it's all any competent programmer needs to start hacking.

Solving #2 proved to be a one-hour exercise in coding (done properly and 
without redundant code-snippets and syscalls). I've implemented this 
in-house in the module for now.

#3 requires rather careful thought and planning. What's a reasonable 
maximum length for host_name variables? I've never seen one that 
approaches 30 chars, while the alias field could well go up to 40 chars 
or so.
This change would have a pretty huge impact, so I think I'll just 
implement it with conversion-routines inside the module instead, 
although some of it should be taken care of with the implementation of 
indexed table lookups. For example, having indexes (as opposed to object 
names) to objects that doesn't require argument lines or other kinds of 
options would be a tremendous memory save and simplification.

#4 can be solved in pretty much only one way as I see it. The most 
flexible, easiest to implement and coolest method would be to have 
modules inject parameters into an array structure as such;

typedef struct config_var {
   char *var_name;
   int flag;
   void *(*func)(int, struct config_var *, char *);
} config_var;

struct config_var static_cfg_vars[] = {
   {"cfg_dir", 0, (void *)handle_cfg_dir_var},
   {"log_file", 0, (void *)handle_random_cfg_var},
   {NULL, 0, NULL}
};

config_var *cfg_vars = (config_var *)&static_cfg_vars; /* set default */

/* pseudo-code */
(iterate until we hit the NULL stop)
match cfg_vars[x]->var_name with cfg input
/* run the proper function. pass the cfg_var entry so all extras are 
sent as well. Very "future"-compatible */
cfg_vars[x]->func(x, cfg_vars[x], cfg_input_string);

This way all a module would have to do would be to copy the cfg_vars and 
add entries before the pointer is sent to the parsing routine. Each 
object type would have its own version of this so as to facilitate most 
(or all) of the things people would want to do. Naturally, this could be 
applied to other stuff (macros?) as well in a similar way.


Thoughts? Comments?

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click