[collectd] I guess we need a config file
Niki W. Waibel
niki.waibel at newlogic.com
Sat Dec 10 18:55:36 CET 2005
On Fri, Dec 09, 2005 at 04:21:06PM +0100, Florian Forster wrote:
> Hello everyone,
> there are two things on my mind:
> 1) Use threads to parallelize the modules (as described before).
good idea, but you need to get rid of ALL *global variables* FIRST.
(is curtime the only one?)
instead you need a function to get the time and in that function
you need to have some locking mechanism!!!
the part of the code that sets the var also needs to use the locking mechanism.
(you might also use a function to set the time).
> 2) I'm in the process of writing a module for MySQL. For that to work I
> need (configurable) username, hostname, port and _password_. Since I
> won't pass the password on the command line I'd say it's time we got
> ourselves a config file.
okay, but please make sure that this file is relativ to --prefix (sysconfdir?).
also make sure that you have an easy way to reread the config file!
(ie squid uses:
Parse configuration file, then send signal to
running copy (except -k parse) and exit.
other programs check SIGUSR1 or SIGUSR2.
> For both issues there's a solution. It's easy and, in my opinion,
> elegant: Pull in `glib'.
> It provides data-structures which we could use,
> simplifies shared libraries, provides thread-abstraction (threadpools,
> also) and, last but not least, has a config parser with a simple and
> powerful syntax.
well, i dont agree...
i'd like to see collecd depending on as less programs as possible.
here is the dep tree of glib:
$ make -f deps glib
:gettext___stage1: expat libiconv___stage1
:glib: gettext libiconv pkgconfig
glib depends on gettext libiconv pkgconfig
gettext and libiconv depend on each other
gettext additionaly depends on expat.
regarding threads i'd suggest the library pth:
also i'd suggest that you add the threading support OPTIONALLY.
people should be able to decide themself if they want to execute all
modules in parallel or one after each other (without the need of a
> Apparently glib's interface hasn't changed much between 1.x and 2.x, so
> I hope to be version-independend. But since I don't have any experience
> with glib I can't promise that..
> Before I start doing big changes, does anyone have anything to note?
> In the meantime, I'll pack another release to get the `users' module
> published ;)
regarding the config file ... hmmm.
i'd really prefer some very simple mechanism.
i guess it would be enough if the files are read line based:
ignoring stuff after a # (until EOL) and lines without :.
if there is a function
char *get_option(char *option);
a plugin could get easyly options.
a function like
int set_option(char *option, char *value);
to overwrite config file options by command line options (like in ssh:
ssh -o option=value) could be useful as well.
also, it would be very nice to load/unload modules during runtime.
but that would mean that you add an unregister or release function to plugin_register:
void plugin_register (char *type,
void (*init) (void),
void (*read) (void),
void (*write) (char *, char *, char *)
void (*release) (void));
(necessary to close filedescriptors or free memory...)
More information about the Collectd