> > The service struct is an internal Nagios structure definition which
> > changes between Nagios versions. If the user module is compiled for
> > use with Nagios 2.0 and it's definition of the service struct, it
> > will have problems if it is not recompiled for future versions of
> > Nagios.
> >
> > Off the top of my head, I could overcome this by requiring that the
> > user modules indicate (by calling a function) what version of Nagios
> > they are compiled for. If they report anything but the current
> > version (or do not report at all), unload them so they can do no
> > harm.
>
> I like the idea a lot, and I can see heaps of potential for some funky
> dynamic monitoring stuff..
>
> In the .h file which modules will #include, add this macro:
>
> #define NAGIOS_API_VERSION(x) int __nagios_api_version = x;
>
>
> Each module must insert (near the top) a nice simple line like:
> NAGIOS_API_VERSION(3)
>
>
> Then, when you dlopen() the module, use something like:
>
> #define REQUIRED_API_VERSION 3
> if (*((int *)dlsym(dlhandle, "__nagios_api_version")) != REQUIRED_API_VERSION)
> {
> printf("Wrong module version... not loading\n");
> return;
> }
>
> to get the version number before you call the init function. If the version
> number is not exactly right, don't load the module. I think that will
> work...
>
> It might be nice in principal to allow multiple versions or some kind of
> backward compatibility, but I doubt it's worth it, for the stability you
> could potentially lose.
>
> Just make sure that you increase the api version in the core code whenever
> you change it, and it'll be sweet.
>
>
> Also, on second thought, it might be worthwhile putting in some compiler
> checking #ifdef blocks, so that an old version of a module won't compile
> with the new headers..
>
Thanks David - this is exactly what I was looking for.
Ethan Galstad,
Nagios Developer
---
Email: [email protected]
Website: http://www.nagios.org
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]