Hello,
Today, I'm working on the nfs plugin (adding stuff for
/proc/self/mountstats). And I thought that supporting reconfig would be
nice. So I'm reading this mail again...
Some new comments are here.
Example:
/* plugin.h */
int plugin_register_reconfig (const char *name,
int (*callback) (oconfig_item_t *));
/* UNIXSOCK */
RECONFIGURE <PluginName>
The question is if this should be considered at all (after all, it's
not
officially supported). However, by splitting the "reconfig" into
"deconfig" and "reconfig" (or "config"), we could easily handle this
situation as well. So, I suggest the following:
Having deconfig + reconfig is definitely a good idea because the
developer has to think how to "free" the memory allocated with
config/reconfig and cannot produce bad code with fastly coded
update_config() function.
- typedef int (*deconfig_cb) (void);
- typedef int (*reconfig_cb) (oconfig_item_t *);
That is, 'deconfig' would use the same signature as 'shutdown' and
'reconfig' would use the same signature as 'config'. This would allow
to
use the appropriate callbacks twice, which in most cases should be
sufficient (probably plus some checks for current settings).
I like typedef int (*reconfig_cb) (oconfig_item_t *);
Because of the same signature as 'config'. But in reality because of
the signature of "config_complex".
What about "config simple" ?
In my mind, most plugins will have the same callback for config and
reconfig. So I suggest :
- typedef int (*deconfig_cb) (void);
- typedef int (*reconfig_cb) (const char *key, const char *value);
- typedef int (*reconfig_complex_cb) (oconfig_item_t *);
About the nfs plugin (currenly having no configuration at all, I will
choose the config_complex mechanism) and will try to support these
definitions (and hack something with stat() again before all this is
implemented).
Regards,
Yves
Any thoughts, comments on this?
As a second step we could then think about also implementing a
"reload"
action. This would mean unloading and reloading the shared object of
a
plugin and then doing a "reconfigure".
In fact, thinking about this again, I think that a global reload
should
not unload and re-load the shared objects (but possibly unload
plugins
that are no longer used and load new plugins). Else, it's gonna be
hard
to keep plugin-global information (caches, etc.) in place.
However, a second operation (available through the 'unixsock' plugin
and
similar) could be used for that case if anybody comes up with a
use-case
for that.
Cheers,
Sebastian
_______________________________________________
collectd mailing list
[email protected]
http://mailman.verplant.org/listinfo/collectd
--
- Homepage - http://ymettier.free.fr
-
- GPG key - http://ymettier.free.fr/gpg.txt
-
- C en action - http://ymettier.free.fr/livres/C_en_action_ed2.html
-
- Guide Survie C - http://www.pearson.fr/livre/?GCOI=27440100673730
-
_______________________________________________
collectd mailing list
[email protected]
http://mailman.verplant.org/listinfo/collectd
