[PATCH] add documentation about backend naming for VMOD authors

Poul-Henning Kamp phk at phk.freebsd.dk
Mon Nov 2 09:03:26 CET 2015

In message <5636AF1F.3010907 at uplex.de>, Geoff Simmons writes:

>>>> But that reminds me:  What was the consensus on my proposal for
>>>> .%d suffix for colliding backend names ?
>The previous conversation was just you and me talking, so I don't know
>if we could call anything "consensus", but one point was that with the
>suffix, VBE stats would exist for every backend. Otherwise, VBE stats
>are only set up for one backend with a duplicated name, and all other
>backends with the same name get no stats at all.

also: CLI commands to set sick/healty etc.

>But you don't have to do it that way. A VMOD author can set up
>everything in a struct director, implementing all of the functions in
>the interface [...]

Sure.  And it can add it to the data structures to appear in the CLI
and add VSM stats chunks.

But I'd rather question the sanity of the VMOD writer, than change
our architecture to accomodate such code :-)

>So unless we add a requirement like "you have to call VCL_Something()
>to 'register' the director/backend", so that VCL_Something() can
>change the name, I don't think we can use suffixes or anything else to
>enforce unique names. (And as of now, I don't see why a VMOD backend
>wouldn't work even if it doesn't call VCL_Something().)

I think there is merit to this, in the sense that I can see why a VMOD
creating dynamic backends wouldn't want them to "pollute" the CLI
and VSM.

But in the case where the VMOD wants the backend to appear in the CLI/VSM,
I think it is perfectly fair to disambiguate the name there, and I think
it would be silly to fail the registration, because some other VMOD happened
to use the same name already.

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.

More information about the varnish-dev mailing list