nebmods API
Andreas Ericsson
ae at op5.se
Thu Feb 10 10:43:49 CET 2005
Ben wrote:
> Speaking for myself.....
>
> 1. I don't really care. It may not be clean as it is today, but it's not
> so hard either. Cleanliness is all well and good, but I'm chasing bigger
> fish.
>
Perhaps so, but it'd be a rather simple fix (although wasted if Ethan
doesn't like it), so it's in the "low-hanging-fruit" category.
> 2. Again, I don't really care, but this time it's because I'm using the
> nagios-db module. Perhaps if I was using other modules I would care
> more. :)
>
True. But for some modules this could be vital info. Adding redundant
code goes against my sense of stylishness.
> 3. If there's anything the history of programming should tell us, it's
> that making fixed-length buffers for strings is a bad idea. There will
> always be an exception. I don't see anything wrong with prefixing the
> strings with their length. This takes care of the networking issues
> quite well. At least, it always has for my projects.
Yes, but it would mean sending several times for a single object, as
opposed to send(sock, &host, sizeof(host), <flags>);
> I'm not exactly
> sure what you mean by "deep memory management",
That you have to enter the struct itself to be able to manage it as a
whole, or memory will leak. Look in the code and you'll see what I mean
free(host->name); free(host->alias); free(host->this_and_that); free(host);
> but make religious use
> of some helper functions and you should be fine. (Yes, there will be a
> lot of mallocs and frees, but last I checked these were nowhere near the
> top of the performance bottleneck list.)
>
True, but they are notorious for causing memory leaks.
> 4. I don't understand this one, so I can't say much about it.
>
Quite simple really, although the code isn't exactly "Programming 101".
Each configuration directive has a function handling it and an arbitrary
amount of flags associated with it. As such, it's trivial to add
keywords to the list and the keyword handling functions could look at
one of the flags to get the variable and then at another flag (cfg_var
offset?) to look up what variable to assign to the value. A simple way
of getting rid of redundant code-snippets and if() else if() in
cfg-parsing. It also inspires better exception handling, since it
doesn't have to be duplicated ad nauseum.
> On Feb 9, 2005, at 12:55 PM, Andreas Ericsson wrote:
>
>> 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
>> _______________________________________________
>> Nagios-devel mailing list
>> Nagios-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>
>
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>
--
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
More information about the Developers
mailing list