Few namespace questions

[Marko Myllynen <myllynen@xxxxxxxxxx>]

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.

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?

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.

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?

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.

localhost:~> pminfo -V
pminfo version 3.10.9
localhost:~> cat ./pmns
root {
  mem
}
mem {
  util
}
mem.util {
  used  60:36:1
  used  60:36:1
}
localhost:~> pminfo -dfmtT -n ./pmns mem.util.free
[./pmns:10] Error Parsing ASCII PMNS: Duplicate name "used" in subtree
for "mem.util"

    Duplicate name "used" in subtree for "mem.util"
    ^
pminfo: Cannot load namespace from "./pmns": Problems parsing PMNS
definitions
localhost:~> pminfo -dfmtT -N ./pmns mem.util.free
[./pmns:10] Error Parsing ASCII PMNS: Duplicate name "used" in subtree
for "mem.util"

    Duplicate name "used" in subtree for "mem.util"
    ^
pminfo: Cannot load namespace from "./pmns": Problems parsing PMNS
definitions
localhost:~> PMNS_DEFAULT=./pmns pminfo -dfmtT mem.util.free

mem.util.free PMID: 60.1.2 [free memory metric from /proc/meminfo]
    Data Type: 64-bit unsigned int  InDom: PM_INDOM_NULL 0xffffffff
    Semantics: instant  Units: Kbyte
Help:
Alias for mem.freemem.
    value 4726316
localhost:~>

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?

Thanks,

-- 
Marko Myllynen