--------
In message <[email protected]>, Mart
in Blix Grydeland writes:
I'm not so keen on vmod_debug _always_ doing this, in particular not
the VSL spamming.
Isn't there some more delicate way we can do it ? From vcl_init{} maybe ?
>---
> lib/libvmod_debug/vmod_debug.c | 33 +++++++++++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
>diff --git a/lib/libvmod_debug/vmod_debug.c b/lib/libvmod_debug/vmod_debug.c
>index 7bd719f..69256d2 100644
>--- a/lib/libvmod_debug/vmod_debug.c
>+++ b/lib/libvmod_debug/vmod_debug.c
>@@ -38,6 +38,26 @@
>
> static int n_init = 0;
>
>+static struct exp_callback exp_cb;
>+
>+static void __match_proto__(exp_callback_f)
>+exp_cb_insert(struct worker *wrk, struct objcore *oc, void *priv)
>+{
>+
>+ CHECK_OBJ_NOTNULL(wrk, WORKER_MAGIC);
>+ VSL(SLT_Debug, 0, "exp_cb_insert: %p", oc);
>+ assert(priv == &exp_cb);
>+}
>+
>+static void __match_proto__(exp_callback_f)
>+exp_cb_remove(struct worker *wrk, struct objcore *oc, void *priv)
>+{
>+
>+ CHECK_OBJ_NOTNULL(wrk, WORKER_MAGIC);
>+ VSL(SLT_Debug, 0, "exp_cb_remove: %p", oc);
>+ assert(priv == &exp_cb);
>+}
>+
> VCL_VOID __match_proto__(td_debug_panic)
> vmod_panic(VRT_CTX, const char *str, ...)
> {
>@@ -74,6 +94,10 @@ fini_function(void *priv)
>
> assert(n_init > 0);
> n_init--;
>+ if (n_init == 0) {
>+ EXP_Dereg_Callback(&exp_cb);
>+ VSL(SLT_Debug, 0, "exp_cb: deregistered");
>+ }
> }
>
> int
>@@ -83,6 +107,15 @@ init_function(struct vmod_priv *priv, const struct
>VCL_conf *cfg)
>
> priv->priv = &n_init;
> priv->free = fini_function;
>+ if (n_init == 0) {
>+ memset(&exp_cb, 0, sizeof exp_cb);
>+ exp_cb.magic = EXP_CALLBACK_MAGIC;
>+ exp_cb.cb_insert = exp_cb_insert;
>+ exp_cb.cb_remove = exp_cb_remove;
>+ exp_cb.priv = &exp_cb;
>+ EXP_Reg_Callback(&exp_cb);
>+ VSL(SLT_Debug, 0, "exp_cb: registered");
>+ }
> n_init++;
> return (0);
> }
>--
>2.1.4
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[email protected] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
varnish-dev mailing list
[email protected]
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
