[pcp] Few namespace questions

[Ken McDonell]

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.