Hi -
nathans wrote:
> Isn't the fix for http://oss.sgi.com/bugzilla/show_bug.cgi?id=1129
> ... just to do a deep copy of the attributes? (i.e. walk the hash,
> copy the attrs from the original context into the dup)
I don't know. The __pmContext structure has several pointy fields,
and investigating the extent to which each can/should be copied or not
is outside my domain of expertiese.
> That seems too easy [...]
I hope it is, good luck!
> Haven't reviewed the rest of the series, but one probable issue from
> your description is that the pmclient tool is a demo program that was
> written to accompany content in the Programmers Guide and man pages -
> rewriting it means there's probably going to be a disconnect with the
> content in the programmers guide now.
Do you believe there is value to retaining the book documentation of
the old pmclient? If so, the new one could be renamed something
creative like pmclient2.c.
> (Hmm, and this new API should probably be added to the programmers
> guide too, I guess.)
Yes, at some point.
> Another thing to think about - if the only use cases so far are
> pmmgr and pmclient (both of which are relatively infrequently used,
> in terms of the installed base),
One can judge an API by how it serves programmers' needs in terms of
source code (and corresponding testing). An API is not validated by
its end-user execution.
> [...] pmstat(1) would seem a good candidate
OK, done. It seems to improve the code.
commit 700392053557088e43505435f66dffbcb0a44bd0
Author: Frank Ch. Eigler <fche@xxxxxxxxxx>
Date: Wed Dec 2 19:04:15 2015 -0500
pmfg: pmstat conversion
Show off application of the fetchgroups api to pmstat.
> and the python APIs of course should expose and use it. It might
> even be helpful to look into libpcp_qmc making use of it too?, or
> maybe pmwebd?
Are y'all imposing all of these as prerequisites for a merge?
- FChE
|