Jeff Squyres wrote:
> $%@#$% Sorry.
> I saw that and fixed it in my local OMPI SVN copy last night as well.
> Here's a patch to make it go (I obviously didn't want to commit this
> until the new PLPA goes in). We *may* want to revise the paffinity
> API to match PLPA, not because Linux is the one-and-only-way, but
> because we actually took some effort in PLPA to make a fairly neutral
Jeff can you work with Pak to make sure this doesn't completely mess up
Solaris' processor affinity methods in OMPI.
> On Feb 19, 2008, at 8:59 AM, Sharon Melamed wrote:
>> The new PLPA fails in compilation. there is a need to change the
>> paffinity API's:
>> 1. max_processor_id with one parameter --> get_processor_info with 2
>> 2. max_socket with one parameter --> get_socket_info with 2 parameters.
>> 3. max_core with 2 parameters --> get_core_info with 3 parameters.
>> I changed these API's internally in my copy of the trunk and tested
>> the new PLPA.
>> it works properly.
>> Do you have an idea how to integrate the new PLPA with the new API's ?
>> On Feb 19, 2008 4:31 AM, Jeff Squyres <jsquyres_at_[hidden]> wrote:
>>> Sharon/Lenny --
>>> Could you try out the newest PLPA RC for me? I think it's ready. I
>>> just posted rc4 to the web site (I posted that rc3 was available, and
>>> then found a small bug that necessitated rc4):
>>> You should be able to do this to test it within an OMPI SVN checkout:
>>> cd opal/mca/paffinity/linux
>>> mv plpa bogus
>>> tar zxf plpa-1.1rc4.tar.gz
>>> ln -s plpa-1.1rc4 plpa
>>> cd ../../../..
>>> ./autogen && ./configure ...... && make -j 4 ......
>>> Let me know if it works for you properly (configure, build, and
>>> function). If so, I think it's ready for release. I'll then do the
>>> SVN magic to bring it to the OMPI trunk.
>>> Jeff Squyres
>>> Cisco Systems
>>> devel mailing list
>> devel mailing list
> devel mailing list