On 19/01/15 11:06, Mark Goodwin wrote:
On 01/17/2015 05:27 PM, Ken McDonell wrote:
[...]
This does not work at all "as is". It can be made to work, but that
involves
changing scores of source files ... the result is an ugly hack hiding
a git
branch and I'm not going to commit that to the dev branch.
On reflection, I think there are 2 alternatives:
1. change the default behaviour to allow duplicates and strip out all
the "no
duplicates" stuff, or
2. drop all pretence at supporting duplicate names and rip out the
associated
non-working stuff.
Thoughts?
I think it'd be good generally, ...
Is that a vote for 1.?
... and from the back compat viewpoint,
e.g. following namespace migrations and PMDA pmns updates, etc. But
how would pmTraversePMNS() work? What other problems are there?
There are no real problems. The PMNS is still a tree. Just that some
of the leaf nodes are labelled with the same PMID.
- no changes at all to pmTraversePMNS() or pmLookupName()
- pmNameID() would return one name (man page already describes
non-determinism if PMNS contains duplicates)
- pmNameAll() would return all of the names ... and I'd change PCP apps
that currently use pmNameID() to use pmNameAll() and report all names
for a given PMID
The only change would be that if a PMDA implementor used the same PMID
twice by mistake, this would not be detected when the PMDA is installed,
but would have to be debugged when you ask for metric A and get answers
back for metric B, ask for metric B and get answers back for metric B.
|