[pcp] How should we approach the loading of the IB pmda as a LOCAL context DSO?

[Corneliu Boac]

I like the proposed solution. This will address the pmclusterd issue.
Thank you everybody.
Please let me know if I can help with anything.

Best regards,
Cornel.

On 03/28/2010 10:03 PM, Nathan Scott wrote:
> ----- "Ken McDonell" <kenj at internode.on.net> wrote:
>
>   
>> On Mon, 2010-03-29 at 10:53 +1100, nathans at aconex.com 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.
>
>