G'day Marko.
Good questions ... answers require some history I'm afraid.
On 30/11/15 04:04, Marko Myllynen wrote:
Hi,
most PCP clients implement the -n option to load an alternative
namespace from a given file. For consistency I was thinking to add this
to pmrep as well but the more I investigated the more unclear the
situation became so I'd appreciate some clarifications here.
-n comes from the very earliest versions of PCP where the PMNS was not
exported by pmcd and not stored in archives (this is the pre-
"distributed PMNS" time, which was just after the demise of the
Hollerith punched card)
It has survived in pminfo (which also dates from that time) for
long-forgotten compatibility reasons, but has been cloned into most
other PCP clients based on mimicry not functional demand.
Beyond some obtuse fault injection justification in QA, there is no real
reason for -n to be supported by any new command.
pmTrimNameSpace() is used only by pminfo but not by any other tool.
Reading pmTrimNameSpace(3) it looks like this is not needed with V2
archives so could perhaps even dropped from pminfo (or if it's useful
should it be added to other tools as well)? In any case, I think this is
not needed for pmrep nor in Python PMAPI, agreed?
We stopped supporting V1 archives some time ago ... the
pmTrimNameSpace() call should be removed from pminfo and the man page
updated to reflect the fact that this is a nop, maintained for backwards
ABI compatibility.
FWIW, seems that pmlogger(1) and pmTrimNameSpace(1) are inconsistent in
that sense that the former says that only V2 archives can be created
while the latter still says V1 archives can be created.
Correct, except that even when pmlogger(1) stopped creating V1 archives
there were still a lot of V1 archives in existence that needed to be
read, so there was a transitional period where pmTrimNameSpace() made
sense. But we're past that now and the V1 support has been removed from
libpcp, and we should have emasculated pmTrimNameSpace() at that time.
pmLoadASCIINameSpace() is currently missing from the Python PMAPI (only
pmLoadNameSpace() is available). Based on pmLoadASCIINameSpace(3) it
looks like duplicates should be allowed since 3.10.3. But when testing I
see that pminfo which should support both modes fail with dupes (see
below), is this a bug?
No. "duplicates" is a bit ambiguous. Your example shows a duplicate
_name_ (mem.util.used) ... this sort of duplicate has always been
invalid. The "duplicates" that pmLoadASCIINameSpace() optionally
accommodates are where two _different_ names have the _same_ PMID.
Change the second "used" to "other" in your test PMNS, and pminfo -n and
pminfo -N will behave as advertised.
Testing with pminfo using the PMNS_DEFAULT environment variable
mentioned in PCPIntro(1) was also unhelpful, looks like PMNS_DEFAULT
requires a pmLoadASCIINameSpace() / pmLoadNameSpace() call with filename
PN_NS_DEFAULT? If so then to me it looks like PCPIntro(1) and the code
are not in sync.
Not sure about this one. PM_NS_DEFAULT has to be passed as an argument
to pmLoadNameSpace() or pmLoadASCIINameSpace() and there are only a
handful of apps that need to do this (pmcd, dbpmda, pmlogger, newhelp,
checkhelp). I don't see any obvious disconnect between PCPIntro(1) and
the code here.
I'm starting to suspect whether any of this is actually needed at all
with tools like pmrep. I can't think of any case where an average user
would ever need this. And I'm having a hard time to come up with a
scenario where even an advanced user would find the -n/-N functionality
helpful. Perhaps if PMNS_DEFAULT would work it might be enough for those
who need it for whatever reason. What do you think?
Just skip -n/-N for pmrep (and any new PCP client) would be my suggestion.
|