[collectd] Generalized ignorelist functionality

Florian Forster octo at verplant.org
Mon Nov 6 19:22:34 CET 2006


Hi Lubos,

On Mon, Nov 06, 2006 at 12:13:18PM +0100, Lubo?? Stan??k wrote:
> Do you mean something like this?
> 
> struct collectlist
> {
> 	int num;
> 	int ignore;
> 	char **list
> } collectlist;
> 
> with functions
> 
> int collectlist_init(struct collectlist *list);
> int collectlist_add(struct collectlist *list, char *inst);
> int collectlist_check(struct collectlist *list, char *inst);
> int collectlist_free(struct collectlist *list);

in general, yes. With minor changes though:

<utils_ignorelist.h>
 struct ignorelist_s;
 typedef struct ignorelist_s ignorelist_t;

 ignorelist_t *ignorelist_create (int inverse);
 void ignorelist_destroy (ignorelist_t *);

 int ignorelist_add (ignorelist_t *, const char *);
 int ignorelist_match (ignorelist_t *, const char *);
</utils_ignorelist.h>

<utils_ignorelist.c>
 struct ignorelist_s
 {
  char *match;
  /* Whatever else is needed */
  ignorelist_t *next;
 };
</utils_ignorelist.c>

I am a big fan of `opaque data types' for this sort of thing: Since
plugins shouldn't care how the ignorelist works internally, they should
not even _know_. This simply prevents wrong usage (i. e. usage of
things, that are not considered part of the public interface). The folks
in Redmond have demonstrated impressingly why it is a good idea to do it
like this ;) If we decide to use a binary tree (b-tree, red-black-tree,
whatever) in the future we don't need to care about plugins at all.

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20061106/bd348825/attachment.pgp


More information about the collectd mailing list