pcp
[Top] [All Lists]

Re: pmParseMetricSpec(3) problems

To: Ken McDonell <kmcdonell@xxxxxxxxxx>
Subject: Re: pmParseMetricSpec(3) problems
From: Nathan Scott <nscott@xxxxxxxxxx>
Date: Thu, 01 May 2008 10:03:49 +1000
Cc: pcp@xxxxxxxxxxx
In-reply-to: <1209594900.2885.13.camel@xxxxxxxxxxxxxxxxxxxxx>
Organization: Aconex
References: <40997.192.168.3.1.1209514118.squirrel@xxxxxxxxxxxxxxx> <1209590407.2870.19.camel@xxxxxxxxxxxxxxxxxxxxx> <54508.192.168.3.1.1209591565.squirrel@xxxxxxxxxxxxxxx> <1209594900.2885.13.camel@xxxxxxxxxxxxxxxxxxxxx>
Reply-to: nscott@xxxxxxxxxx
Sender: pcp-bounce@xxxxxxxxxxx
On Thu, 2008-05-01 at 08:34 +1000, Ken McDonell wrote:
> 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.

I'm in favour of the latter, even having had the history
lesson, for the reasons I mentioned earlier - mainly the
option for (even) less CPUburn when running kmchart, the
ability to run it without a network (heh, ok, thats just
my occassionally wierd setup), and most importantly as a
way to reduce the barrier-to-entry for people trying out
kmchart (no need for pmcd running, and everything can be
run as a regular user with no additional priveledges).

As discussed, the @:<metric>[inst] syntax sounds good to
me.

cheers.

-- 
Nathan


<Prev in Thread] Current Thread [Next in Thread>