G'day Frank.
On 26/07/15 22:07, Frank Ch. Eigler wrote:
...
(Did you consider using plain /bin/cpp? But see below.)
I have considered cpp (both previously and again before making these
pmcpp changes), but cpp is really not a starter here ...
1. the package prereq dependency chain just gets a lot longer ... many
production machines have no toolchain installed, so no cpp
2. cpp is too closely linked to C ... we use the # comment delimiter in
lots of config files, and the tokenizing and macro substitution of cpp
does not map well onto our files (there is no equivalent of pmcpp's -r
to restrict macro expansion to just ?name or ?{name} where ? is % or #
depending on -s or not and expanding name anywhere the cpp's tokenizer
isolates it is not cool.
3. cpp typically starts with a kitchen sink of predefined macros that
can have unexpected consequences when a predefined macro name is
innocently lurking in a pmlogger configuration file
4. there are lots of cpp versions, and sticking to a lowest common
denominator has proven tricky in the past (not all of the above apply to
all the cpp variants)
pmcpp tries to deliver functionality close to cpp without these
disadvantages.
...
These are real nice for abbrevation - anything else?
- common include files for repeatedly useful pmlogger stanzas
- conditional expansion based on macros that can be defined or undefined
elsewhere, like a private config file that might be as simple as
%undef cpu_detail
%define cpu_all
%include "cpumetrics"
- parameterization of logging frequencies so they can easily be changed
without editing the whole pmlogger configuration file
The sorts of logic I've been hoping for in the pmlogger language are
more sophisticated switching capabilities (more than "probe ..." as
per pmlogconf), for example:
- to exclude non-container-related metrics if running within a
container
- to vary the configuration according to -run-time- variables like
other metrics (or pmie expressions), so as to dynamically adjust
logging intensity according to specified conditions
- enough smarts to express the pmlogconf language directly, so we
can ditch the super-slow pmlogconf implementation
For such things, it's the "%if $condition" consruct that's key, for
rich enough $condition.
While I sympathize with replacing pmlogconf (use has probably outgrown
the original idea), I am not inclined to support loading pmcpp with too
much more expression evaluation logic ... this seems like the opening of
a very deep pit.
On the other hand, there is this thing called, er, the shell, that can
be scripted to be really good at running arbitrary expression
evaluation, probing, sniffing and generally figuring out the "right
thing"(tm).
If I was to augment my pmcpp changes with a new
%shell "arbitrary command" (or #shell "arbitrary command" if no -s on
the command line)
then I think this could address your issues ... the %shell gets replaced
by the output from "arbitrary command", just like %include, and this
could include fragments to %define or %undef macros that would influence
the resulting pmlogger config.
Specifically these two would be equivalent:
%include "file"
%shell "cat file"
if file was local or an absolute pathname (no extra searching in the
%include case), but the %shell one could be extended to do a whole lot
more, including container-based suppression, adjust logging frequency
before pmlogger is launched, etc., probe and set to do the moral
equivalent of the pmlogconf conditionals.
This could be done (a) after package installation for one-off platform
dependencies (run pmcpp and salt the output away), and/or (b) on the fly
via pmlogger's invocation of pmcpp (which becomes unconditional in my
next round of commits).
If you'd like %shell added to the pmcpp arsenal, send in your votes.
|