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@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.
>
>
|