----- "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> wrote:
> On Mon, 2010-03-29 at 10:53 +1100, nathans@xxxxxxxxxx wrote:
> ...
>
> Since this is such a low frequency usage, I'd probably opt for the
> simpler
>
> #define PMDA_BLAH 903
> #define PMDA_FOO 104
>
> in the source code that calls __pmAddLocalPMDA().
>
Yep, OK, sounds fine.
> > - .so is platform specific (dylib on mac, dll on win) ... it would
> be
> > a good idea to hide that aspect (platform differences) from the
> caller.
>
> Would not be hard to have the code check for the existence of name,
> name.so, name.dylib, name.dll, ... and use the first found file ...
> would this work?
Just testing the one $DSO_SUFFIX for the local platform would do I think
(falling back to auto-appending suffix if the requested file not found),
also, prepending $PCP_PMDAS_DIR? - I think that was the original intention
from your example before which had a relative path IIRC?
> > - should there be a way to remove entries from the table too? Or
> at
> > least start from a clean slate?
>
> Yeah, I toyed with that but laziness won out ... I can revisit the
> issue, but rather than a 3 or 4 more routines, I'd probably go the
> ioctl() path and change to __pmLocalPMDA() with an additional first
> argument being an opcode for one of ...
> - ADD
> - DEL (match domain number _or_ dso name)
> - CLEAR (remove all entries)
>
> Should I do this?
Yeah, I think that would be good.
> >
> > Sounded earlier like the current cluster PMDA source (in oss tree,
> not
> > released by SGI from that tree yet, I guess?) is completely broken,
> so
> > simply adding a configure-and-fail check there would be a good
> start.
> > Guess we could bump the libpcp shared library soname too (ouch).
>
> I'd suggest not bumping the soname version this for this particular
> change, it just ain't worth the pain of many for the gain of so very
> few. ... 8^)>
Yep, vigorous nodding here!
cheers.
--
Nathan
|