Visibility of VCL source (Was: Re: [PATCH] vcl.show expand includes)

[Poul-Henning Kamp]

In message <69611.1406020117 at critter.freebsd.dk>, "Poul-Henning Kamp" writes:
>In message <CAEh05Va0upueb8CDQEdNh=NXhpf_=rZ1iTfr5EKzrR9tFyi9Hw at 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.

Sorry, meant: "... only expose it via CLI ..."

>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
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.