In message <CAEh05Va0upueb8CDQEdNh=NXhpf_=rz1itfr5ekzrr9tfyi...@mail.gmail.com> , Dag Haavi Finstad writes:
>As discussed on the Stockholm VDD, here's a proposal for #1457. >[...] >The VCLs are output in the same order as they appear in the VCL >location/profiling table in the compiled VCL (the vcl->ref stuff used >in the VCL_trace records), so if someone wanted to do a VCL code >tracer thing, that should be possible. I'm not at all happy with the fact that we still dlopen() VCL's for vcl.show(). That exposes the master process in ways I don't like, even more so now we have VMODS which pull in strange libraries. One way to fix it is to accept that we cannot show the source unless the child process is running. I can live with that. If that is not acceptable, we could fork a child of master to dlopen() the compiled VCL (we already do that for testing) and pull the source out of that. But all in all I prefer to make the child responsible, so that we don't dlopen() compiled VCL's unnecessarily. If we go that route, we can do as now, and only exposed it via VCL or we can expose the counters and VCL source via VSM to avoid the VCL overhead. The latter is probably best for interactive visuals, but does expose the VCL source without CLI auth check. I'm not sure if that is OK. Input ? -- 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
