[PATCH 3/5] Pass the VRT_CTX down to the vmod init function

[Poul-Henning Kamp]

--------
In message <1433927162-17564-3-git-send-email-martin at varnish-software.com>, Mar
tin Blix Grydeland writes:

After due consideration I have decided that I do not want to expose
the CLI to the vmods.  I belive that is also why we never really
did, despite the field technically being there.

Instead we should expose just a VSB and report its contents in the
CLI in case of error.

I'm a bit worried about quality of error messages here, so we may
want the VCC to emit code along the lines of:

	VSB_clear(ctx->vsb);
	VSB_cat(ctx->vsb, "Initializing vmod_debug:\n");
	if (VRT_Vmod_Init(&VGC_vmod_debug,
            &Vmod_debug_Func,
            sizeof(Vmod_debug_Func),
            "debug",
            "/critter/Varnish/trunk/varnish-cache/lib/libvmod_debug/.libs/libvmo
d_debug.so",
            "PQVQBUUFQXFQEDALV at NCKOZKMBDGXJRU",
            ctx))
                return(1);
	VSB_clear(ctx->vsb);

so that we are sure the message tells us which vmod emitted "File
Not Found" or such non-informative messages.

Related to this:

Should the vmod-fini function also be able to fail?

This would allow vmods to veto dlclose() for instance when threads
are not stoppable etc.

Of course this is sort of an invitation to not bother writing proper
cleanup mechanisms for fini() to begin with.

However, I very much suspect that temptation to be there no matter
what we do, so providing a way to clearly signal this fact and
thereby avoiding panics may be a good idea ?


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.