phk at phk.freebsd.dk
Thu May 18 09:15:56 CEST 2017
I have been prototyping the extensible VSC-stuff for some days and
this is a progress report of sorts.
The major issue with extensible VSC's is that they need to document
themselves so varnishstat(1) and other VSM users can understand them.
The layout of a VSM segment follows directly from that:
uint64_t offset_to_doc; // N * 8
The documentation should have 1+N parts, a "head" which explains what
this set of counters is about, and a "stanza" for each counter.
The 'stanza' tells the type (counter/gauge/bitmap), the level
(info/diag/debug) and maybe also unit of this counter.
It must have a "oneliner" and optionally also a multi-paragraph
And then we run into the how do we encode that in the VSM segment
thing, and after looking at all the alternatives I could imagine,
I end up with JSON ... again, again, again.
I have a small, 500 LOC, json parser in C we can use, so that is
not going to drag in a dependency.
If we're going to bite the JSON bullet, the other places it makes
sense to use it, is for the vcc_if.c::Vmod_Spec data structure
which explains the contents of a VMOD to VCC.
Given that we are going to expand what VMODs can contain, that
"minilanguage" needs expansion too, so all in all, I think we
are over the threshold were JSON makes sense.
... but I still feel dirty using JSON to pass data structures
from one C-program to another, or as it may be, from a python
program to another.
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