Comment # 2
on bug 1133
from Frank Ch. Eigler
> [...]
> Is a fetchgroup client likely to be asking for event.* metrics?
That would be the natural way of grabbing the flags / missed-event counter. We
don't have sophisticated event consumers at all at the moment, but one can
imagine those being useful someday.
> If yes, is this likely to be explicit or are they expected to be found in a
> PMNS traversal from the root of the PMNS?
In the fetchgroup case, the former - so perhaps one could teach the
pmLookupName/Desc part about them, if we can't put them into the PMNS properly.
The key is to have the names be accessible -before- the pmUnpackEventRecord*
call.
It would be possible for fetchgroups to paper over this problem by making a
dummy pmUnpack* call on a dummy pmResult* during the registration phase, just
to trigger the registration code.
> If you could give me some use cases, I'll see if there is (a) a different
> place to pre-emptively register the metrics that would work for you, but not
> burden everyone else [...]
FWIW, fetchgroups aren't that special - the way that these magic metrics were
added impedes normal pmapi flows too; forces name lookups to occur within a
decode loop.
(By the way, having you be the default assignee for new oss.sgi.com/bugzilla
pcp reports should probably be changed. These problems are generally not in
code you wrote.)