----- "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> wrote:
>
> On Thu, 2009-11-05 at 14:36 +1100, Nathan Scott wrote:
> > Hi Ken,
> >
> > ----- "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> wrote:
> > Hmm. That seems quite unwieldy (obviously, wont work on Windows
> too).
> > What's the rationale for that instead of working in libpcp
> directly?
>
> The real rationale is that for GNU/Linux the compiler/linker folk
> never
> really understood the deeper issues of ABI compatibility and
> certainly
> have not come close to the elegance of the IRIX approach to evolving
> DSOs with optional symbols.
We haven't used the existing infrastructure for this kind of thing
yet (and really should at some point) - the ld(1) --version-script
does allow multiple API versions to be specified in a single .so &
we haven't explored using that at all so far.
> For this reason I'm hesitant to change the libpcp API/ABI.
>
> But I'm willing to be persuaded on this point.
An example of the above --version-script file syntax:
http://git.savannah.gnu.org/cgit/acl.git/tree/exports (that's as
used by libacl on Linux - pretty straightforward syntax and I think
does some of the things you're after here... maybe, hopefully?).
> There is certainly no architectural obstacle to putting the
> functionality into libpcp rather than as wrappers to the libpcp
> routines as I was proposing.
I'd be much happier with that, esp. having the functionality made
available transparently & in the same way for all platforms.
>
> My goal here was to NOT require any application changes ... hence the
> streams model analogy. The examples you give suggest that the
> applications might be modified to understand about derived metrics.
>
> On reflection I think we may be able to do both.
>
Should focus on doing it in the ideal way, and if applications need to
change to make use of the new functionality, then so be it.
> As an early initialization (this bit is a little tricky, but I think
> pmLoadNameSpace or pmNewContext have to be called before anything we
> care about could be called), I'll check for $PCP_DERIVED_CONFIG being
> defined in the environment and if it use, register (see below) the
> derived metrics from that configuration file. As a prop for
> platforms
> that don't have environment variables the routine
> pmLoadDerivedConfig(char *path)
> may be used to explicitly register derived metrics from a config
> file ... so this could be used with command line glue to load one (or
> indeed more) configuration files as and when an application chooses.
Its not clear that PCP_DERIVED_METRIC buys us anything? Seems a very
painful-to-use interface when compared to just specifying a formula for
the new metric "inline" as one would specify any other metric name.
> To register a derived metric, the routine
> pmRegisterDerived(char *name, char *expr)
> is used. The name needs to come from the expression definer, because
> this (a) acts as the handle for subsequent PMAPI calls, and
> pmLookupName() in particular, and (b) defines where the derived
> metric should be spliced into the PMNS.
>
> By exposing this routine, ...
> 1. I am committing to the "change libpcp" path, so the earlier
> comments
> about ELF and $LD_PRELOAD are not longer relevant
> 2. pmval could be modified to parse
> pmval "cputime = simple.time.user + simple.time.sys" ...
> (the delta() is not needed here, but would be needed in the
> delta(v1) / delta(v2) class of expressions) and then pmval could
> call
> pmRegisterDerived("cputime", "simple.time.user + simple.time.sys")
> 3. pmchart can go crazy with the definition of derived metrics via
> the
> GUI (and possibly saving them for later reloading or auto
> reloading)
Thats good, but still seems a little clumsy - not clear that routine
is needed - could pmLookupName just do it all, if it detects a name
assignment, along the lines:
char *names = { "new.metric = sample.one + sample.two", "sample.one" };
if (pmLookupName(2, &names, &pmids) < 0) ...
(obviously, thats more hard-coded than most tools would use... but any
metric "name" containing an assignment is invalid as a traditional name
and would be easy to detect in pmLookupName).
> Is that closer to meeting your needs?
Yep, definately getting there.
cheers.
--
Nathan
|