------------7NhE3WuB9OnU6N9D2A0R5Y7
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C56D26.05393FF0"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C56D26.05393FF0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: Quoted-Printable
> Yes and no. The comments were in french, much of the code wasn't=20
> indented and mnemonic identifiers doesn't appear to be in the=20
> 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.
And if you prefer a different indenting style, it is not a problem.
=20
> A simpler solution to the same problem would be to implement real=20
> hashing instead of the algorithm in current use. Presently it=20
> generates=20
> worse hashes than an internet checksum function and the=20
> compare_hashdata* functions (called from find_*) are=20
> extremely expensive.
I agree but I saw it as another issue. Of course, the current pseudo-hashin=
g
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.
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 improvemen=
t
versus quantity of changes in code.
> nagios-db isn't the ultimate solution, although using a=20
> 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.
> I'm not so sure about this patch you've proposed though. By=20
> necessity it=20
> involves a fair deal of pointer voodoo. Code such as that is=20
> always hell=20
> to maintain, and it gets increasingly difficult to ensure support for=20
> various compilers and architectures. F.e., gcc aligns components of=20
> datastructures on sizeof(register) boundaries with certain=20
> optimization=20
> options, and squeezes them with others, making pointer-hopping using=20
> anything but relative offsets a debugging nightmare. Other compilers=20
> 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 as parameter. This way, the cod=
e
is twice more complex, but 14 times smaller
.Another thing is the serialize/unserialize functions for status data. If th=
e
program status data used a structure, and if the core and the CGIs used
common structures to store the host & service status data, this code could
use the object generic code, which would suppress nearly everything from
xsdng.c.
And, another idea, involving more changes, can be to reorganize all these
structures in the core after the configuration is read from the obj cfg
files. At this time, except for strings that would be treated as individual=
mallocs, we know how much size we need for
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]