On 28/03/2012 10:07 AM, Nathan Scott wrote:
It's sufficiently confusing that it might be worth tackling (i.e. making
pminfo use pmParseMetricSpec
and set a profile if a single instance is requested) ... but, I have
some vague memory of some people
not wanting that (extra complexity in pminfo? not sure - it does have to
handle the case of the request
not being a leaf node). I can't remember the details though, maybe Mark
or Ken can. I would vote
for doin' it FWIW, unless theres a compelling case - it comes up often
enough, and its a bit confusing.
I suspect it is worth making this change.
The original history (if I recall it from so long ago) was that pminfo
needed to be as lightweight as possible (the Akmal factor for those who
remember) and this was before pmprobe existed. The extra PDU
round-trips to fetch and validate the instance domains were to be avoided.
Using pmParseMetricSpec() would
- hide all the hard work
- not involve extra PDUs for the default case with no instance specification
- make pminfo, pmval, pmevent, pmlogsummary and pmduptext honour the
same syntax for metrics and metrics with instances (pminfo is the only
one not doing this at the moment)
The only wrinkle I can see in this is using pmParseMetricSpec with a
derived metric ... I am not sure if this has ever been tested (there is
no obvious test case in the QA suite) ... but this is a problem (maybe)
that would be common to all the users of pmParseMetricSpec(), not just
pminfo.
|