----- "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> wrote:
> On Sat, 2010-03-27 at 08:23 +1100, nathans@xxxxxxxxxx wrote:
> > ----- "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> wrote:
> >
> ...
> Don't you just hate it when the mail arrives after you've written the
> code?
Sorry 'bout that.
> I don't think overloading the name argument to pmNewContext for the
> type PM_CONTEXT_LOCAL case is going to work ...
OK - *nod*, no worries, just wanted to put it out there in case it helped.
> The solution I've coded uses a new routine to register additional DSO
> PMDAs for use with PM_CONTEXT_LOCAL. The example above would become:
>
> if ((sts = __pmAddLocalPMDA(104, "foo/pmdafoo.so", "init_foo")) < 0)
> {
> // exercise for reader
> }
> if ((sts = __pmAddLocalPMDA(903, "/home/me/secret/place/blah.so",
> "blah_pmda_init")) < 0) {
> // exercise for reader
> }
> ...
> sts = pmNewContext(PM_CONTEXT_NULL, NULL);
>
Seems better than overloading new context as an API (assume you meant
PM_CONTEXT_LOCAL at the end there?). A few other considerations:
- hard coding the domain numbers doesn't really make for readable code,
wonder if we should install stdpmid as a header? or perhaps figure out
the domain number from stdpmid on the fly and remove that 1st argument?
- .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.
- should there be a way to remove entries from the table too? Or at
least start from a clean slate?
> The only down-side I can see of the new libpcp routine is that it is
> hard to properly control making this change and the corresponding
> change
> the cluster PMDA (which triggered all of this) ... since they are in
> different packages.
>
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).
cheers.
--
Nathan
|