Oops, sorry for missing the whole point!
Since the original rationale for PM_CONTEXT_LOCAL no longer exists (let
me know if anyone is interested in the history lesson), and it was
probably a bad idea even at the time, much less now, I'm curious why
this one is of interest.
Killing off PM_CONTEXT_LOCAL would solve your problem ... 8^)>
Alternately, choose a character that cannot be part of a valid hostname
(e.g. @) and declare that @:metric means PM_CONTEXT_LOCAL ... in which
case "host" would be specified in the string, and isarch would not be
used as an input parameter, and extend isarch in the return result to be
-1 or 2 for PM_CONTEXT_LOCAL.
In the open source code base, pmParseMetricSpec() is only called from:
src/libpcp_pmc/src/Metric.c++
src/pmdumptext/pmdumptext.c++
src/pmval/pmval.c
so we're probably not looking a big risk even if the API semantics are
bent a little to accommodate PM_CONTEXT_LOCAL.
On Thu, 2008-05-01 at 07:39 +1000, nscott@xxxxxxxxxx wrote:
> ...
> But, my issue was local contexts (not pmcd) - I don't see any way for a
> pmMetricSpec to specify this third kind of context today, and not sure
> what the best approach to take to implement that is.
> ...
|