Nathan,
I know you don't particularly like the environment variable approach,
but following the $PCP_DERIVED_CONFIG example, we could introduce
$PCP_LOCAL_CONFIG that might specify the name of a file (perhaps stashed
in $HOME/.pcp at the user's discretion) that contained local PMDA
specifications (in the syntax for __pmSpecLocalPMDA that was recently
created).
So in your case, the file might contain
clear
add,60,linux/pmda_linux,linux_init
add,70,mmv/pmda_mmv,mmv_init
add,123,aconex/pmda_aconex,aconex_init
or indeed, simply take the default and add the aconex PMDA, as in
add,123,aconex/pmda_aconex,aconex_init
In some ways this is less ugly than the -K stuff for cases where the set
of PMDAs you'd like to be available for PM_CONTEXT_LOCAL is non-standard
and fixed.
Thoughts?
Of course all of this is moot until the issues with PM_CONTEXT_LOCAL and
dynamic pmns entries is resolved, because until then the mmv metrics
will remain hidden for clients using PM_CONTEXT_LOCAL contexts.
On Mon, 2010-04-12 at 15:31 +1000, nathans@xxxxxxxxxx wrote:
> ----- "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> wrote:
>
> > This is pretty much outside the scope of what I was aiming for with
> > the dynamic metrics, although it is not unreasonable.
> >
> > It will mean even more code being copied and changed from pmcd to
> > libpcp
> > as the current code in the library has no support for making the
> > needed DSO calls.
> >
> > So it is not a simple change.
> >
> > The mmv pmda will sneak in on the back of the default dso table for
> > PM_CONTEXT_LOCAL, but how will you get the aconex pmda into the dso
> > table (pminfo -L -K 123,aconex/pmda_aconex.so,aconex_init ... in the
> > bash stuff)?
> >
>
> Good point. I'll go with dropping -L in the bash completion, I think.
> Guess we could do something like the /etc/ld.so.conf.d/ approach with
> local context pmdas, to specify all that should be open when clients
> open local contexts, but probably overkill at this stage (but perhaps
> thats worth thinking about, instead of putting -K in all the tools?).
>
> Hmmm, probably not a good time to be suggesting that, now that all the
> work is done ... :)
>
> cheers.
>
|