Hi guys,
----- Original Message -----
> On 10/11/14 17:26, Nathan Scott wrote:
> > ...
> Looks like we've made a mistake when the pmdadynamicFoo stuff was added.
> Based on a quick code inspection, I think this prototype
>
> typedef int (*pmdaUpdateText)(pmdaExt *, pmID, int, char **);
>
> should have included another int parameter to allow the "type" from
> pmdaDynamicLookupText() to be passed through to the callback routine
> registered via pmdaDynamicPMNS() that I'm guessing your PMDA is using in
> its own version of pmdaText() (rather than the default one).
For dynamic metrics we can't use the libpcp_pmda pmdaText (aka pmdaGetHelp,
ie the compiled/mapped help text files).
There's a bit of missing functionality here that Martins found: we provide
no way for PMDAs with dynamic metrics to get library help for their metric
text. This is fundamentally because the compiled text files have PMIDs in
'em, and we're using dynamic namespace entries. IOW, at the time the help
files would usually be compiled (eg ./Install time) the pmns is not known,
so newhelp(1) has no chance.
Maybe we should have an option for libpcp_pmda to handle non-compiled help
text entries (ie. the plain text files with metric names instead of PMIDs)?
Not sure how much that would help in general, but it probably would in this
case where we could map the two sets of metrics to one set of help texts.
> This means you can't get indom helptext either for a dynamic indom that
> is associated with a dynamic metric (and otherwise unknown to the PMDA).
Not sure this is a real issue - the (custom) help text callbacks have to
deal with indoms (if present & help exists) themselves - and can do this
by simply calling pmdaText like proc does now. The dynamic code is all
about dynamic metric names, indoms are not really covered (and nor should
they be, I think?).
cheers.
--
Nathan
|