On Thu, 18 Nov 2010 14:04:25 +1100, Ken McDonell wrote:
[ some hand editing of the comment below - too many FETCH_DYNAMICs]
kenj> I think there is a cleaner way to get what you want without
kenj> breaking old PMDAs or adding a new PM_TYPE (which is pretty
kenj> pervasive) with the proposal below to be added to the
kenj> PMDA_INTERFACE_5 changes I've already committed (returning
kenj> PMDA_FETCH_DYNAMIC would be the key) ...
kenj> for metrics of type PM_TYPE_STRING or PM_TYPE_AGGREGATE, use
kenj> PMDA_INTERFACE_5 or later, where the pmdaFetchCallBack method
kenj> called from pmdaFetch() is able to return multiple state
kenj> indications, namely
kenj> * < 0 for an error
kenj> * 0 (or PMDA_FETCH_NOVALUES) for no values
kenj> * 1 (or PMDA_FETCH_STATIC) for a value that should not be
kenj> freed
kenj> * (or PMDA_FETCH_DYNAMIC) for a value which can be freed
kenj> once __pmStuffValue() has been called
kenj> Max, would the address your concerns?
That would do nicely.
kenj> I need to think about what sane subset of the pmda-malloc.html document
kenj> should be included in the pmdaFetch(3) man page, where I agree we should
kenj> document how all this is supposed to work for the hapless PMDA
kenj> implementor.
I've pushed a change to pmdaFetch(3) to add an example of dealing with
strings - nothing as comprehensive as your analysis, just a hint about
the possible problem.
I think at the very least the explanation about PMDA_FETCH_XXX values
must be in the manpage, the rest would be a nice addition to
007-3434-005 if it ever escapes SGI.
max
|