[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