From: Andreas E. <ae...@op...> - 2012-08-07 19:56:39
|
On 08/07/2012 07:24 PM, Jochen Bern wrote: > On 08/07/2012 03:21 PM, Andreas Ericsson wrote: >> [...] Each module gets to keep its own data and Nagios doesn't need to >> know anything at all about it (although it would be neat if it could >> issue a callback and get a key/value vector when printing status data). > [...] >> It would ofcourse be nifty if modules *did* know about each other's >> data, assuming they explicitly request it, but that's not what you're >> talking about so let's ignore that for now. > > FWIW (and not that I've ever coded such a thing myself), if two modules > would *want* to share data, all they would need beyond the OS' shared > memory support would be unique module IDs, a means to coordinate startup > priority (so that the module that actually *creates* the shared memory > can do so before the "user" modules ask for it), and a means of > user-module---to-nagios-core---to-creator-module "hey creator module, > hand me the necessary access data!" requests. Assuming that there are no > "malevolent" modules you have to protect the same data against, that is. > That is over the top. The idea suggested by John is really good to find random module pointers. The using module needs to know about the data from the module it uses anyway, and a one-time lookup from all loaded modules is no big deal. And the list is already there, btw. So we'd add something like void *nebmod_get_ancillary_data(const char *module_id); int nebmod_set_ancillary_data(const char *module_id, const void *ptr); to nagios core. The writing module uses the set call. The reader module uses the get call. Both provide the same module_id and the rest happens automagically. > One thing that needs to be pinpointed for your object IDs, however, > would be their (guaranteed) lifetime. Should they be persisted until the > next reload, restart, or even across config changes (say, a host getting > renamed)? After all, saying that "it's the module's business what data > to attach to the ID, I don't care" maximizes the chance that someone'll > write a module whose extra data then suddenly has a legitimate *need* to > be persisted. > The calling goes like this: nagios -> modules: Modules, create your ancillary data! writer -> nagios: Here it is. Enjoy. reader -> nagios: Ain't got none. Sorry. nagios -> modules: Modules, get your ancillary data! writer -> nagios: Don't need any. Thanks though. reader -> nagios: Ooh, nice, I'll have the data from module X please. nagios -> reader: Here ya go, son. Enjoy! At reload (or restart, or shutdown): nagios -> modules: Modules, release everything that can't persist! modules -> nagios: righto, releasing right away, SIR! That last one's already there in the form of an unload event that modules get when Nagios reloads or shuts down, so only two new callbacks are really required, although I'm guessing modules can probably get over those two first steps without us adding any more callbacks though. On a sidenote, that's probably the weirdest pseudo-code I've ever written. I hope you get the idea though. -- Andreas Ericsson and...@op... OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. |