On Fri, 2010-11-19 at 11:12 +1100, Max Matveev wrote:
> 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.
OK I'll commit the necessary changes, but they'll be rolled up with the
event records changes that are getting close (it touches a lot of the
same code).
> 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.
007-3434-005 will never see the light of day, so I'll merge your
additions and summarise my notes into an expanded man page.
Thanks Max.
|