>>Yes and no. The comments were in french, much of the code wasn't
>>indented and mnemonic identifiers doesn't appear to be in the
>>programming style you use, so it took a while to grok all of it.
>
>
> Right. The only thing I wanted was to know if it could be interesting from
> your point of view. I didn't expect people to look at the code. Actually, I
> wanted to know if it was worth the pain to cleanup the code, to comment it,
> and to write a documentation. I spent more than one week on this code and,
> before going on, I wanted to submit an alpha version.
>
Good plan.
> And if you prefer a different indenting style, it is not a problem.
>
That was just me being stupid. I was reading the patch rather than
applying it and running indent (I can't read Ethan's code either).
>
>>A simpler solution to the same problem would be to implement real
>>hashing instead of the algorithm in current use. Presently it
>>generates
>>worse hashes than an internet checksum function and the
>>compare_hashdata* functions (called from find_*) are
>>extremely expensive.
>
>
> I agree but I saw it as another issue. Of course, the current pseudo-hashing
> system is not very efficient but, until it gets suppressed, it is better to
> transmit the hash tables to the CGIs instead of having them rebuild them.
The largest problem isn't building the hash-tables, but using them to
find things. In many cases the cgi's won't need all the data but will
read all of the configuration anyways. This is a major slowdown that
won't go away until there's some other engine doing (proper) hashing and
serving what the cgi's want (i.e. an RDBMS).
> There are also too many mallocs in the current nagios code, and several
> memory leaks. But, once again, I tried to find the best ratio of improvement
> versus quantity of changes in code.
>
I think you're wrong about the memory leaks (although I whole-heartedly
agree about the malloc()'s). Nagios has struggled recently with severe
memory leaks and some valgrind sessions has narrowed it down to
virtually nothing. Perhaps you aren't running recent CVS code?
>
>>nagios-db isn't the ultimate solution, although using a
>>database is far superior to flat-files (regardless of format).
>
>
> Certainly for the version where CGIs are replaced by some PHP code. And,
> when it is time to work on it, I will be happy to participate. But I have a
> problem now, and I need a solution before one or two years. If you tell me
> that this version 3 is planned for 3rd quarter 2005, it is OK and I won't
> try to add such code.
>
> Yes, storing information in a database can be better as an alternative, but
> I am not sure that the flat file option will disappear soon.
>
Neither am I, but it will disappear sooner or later. How about starting
to work on that PHP Gui right now then? I think the nagios-db
neb-modules also updates tables which aren't materialized, so using the
data collected by nagios-db but without materialized views (I really
don't like those) is always an option.
>
>>I'm not so sure about this patch you've proposed though. By
>>necessity it
>>involves a fair deal of pointer voodoo. Code such as that is
>>always hell
>>to maintain, and it gets increasingly difficult to ensure support for
>>various compilers and architectures. F.e., gcc aligns components of
>>datastructures on sizeof(register) boundaries with certain
>>optimization
>>options, and squeezes them with others, making pointer-hopping using
>>anything but relative offsets a debugging nightmare. Other compilers
>>have similar symptoms.
>
>
> Yes. This is the drawback. The current structure of the memory used by the
> core makes it quite complex to serialize. Let me just add that we could
> assume that the core and CGI code are compiled on the same machine by the
> same compiler. I know that the code is complex and I already spent much
> debugging time on it. Actually, the really complex part of the code is in
> serialize_object_section(). As I wanted to keep it small, I did a generic
> function, which takes an object description
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]