Re: [OMPI devel] PLPA ready?
Sure. -Original Message- From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On Behalf Of Jeff Squyres Sent: Thursday, February 21, 2008 6:58 PM To: Open MPI Developers Subject: Re: [OMPI devel] PLPA ready? Sounds perfect. How about this -- since your and my changes are inter-dependent, can you send me a patch for the paffinity change? I'll apply it at the same time that I apply the new PLPA (later today). Thanks! On Feb 21, 2008, at 7:39 AM, Sharon Melamed wrote: > Yes, I think we should change paffinity.h and > paffinity_solaris_module.c and > paffinity_windows_module.c . > > I added those API's some time ago based on the plpa API's. Now, the > plpa API > has changed and no one uses those API's. (Except me and in the > future, maybe > Sun guys) So I don't see why not change those API's including their > signature in paffinity.h > > Sharon. > > -Original Message- > From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] > On > Behalf Of Jeff Squyres > Sent: Thursday, February 21, 2008 5:19 PM > To: Open MPI Developers > Subject: Re: [OMPI devel] PLPA ready? > > On Feb 21, 2008, at 7:13 AM, Jeff Squyres wrote: > >>> Right, but the plpa_solaris_module.c file will need to be updated >>> with >> the new function signatures so that it will still compile (i.e., if >> you're going to be changing the function signatures in paffinity.h). > > > Hah -- I meant paffinity_solaris_module.c. :-) > > -- > Jeff Squyres > Cisco Systems > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel linux-paffinity.patch Description: Binary data
Re: [OMPI devel] PLPA ready?
Sounds perfect. How about this -- since your and my changes are inter-dependent, can you send me a patch for the paffinity change? I'll apply it at the same time that I apply the new PLPA (later today). Thanks! On Feb 21, 2008, at 7:39 AM, Sharon Melamed wrote: Yes, I think we should change paffinity.h and paffinity_solaris_module.c and paffinity_windows_module.c . I added those API's some time ago based on the plpa API's. Now, the plpa API has changed and no one uses those API's. (Except me and in the future, maybe Sun guys) So I don't see why not change those API's including their signature in paffinity.h Sharon. -Original Message- From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On Behalf Of Jeff Squyres Sent: Thursday, February 21, 2008 5:19 PM To: Open MPI Developers Subject: Re: [OMPI devel] PLPA ready? On Feb 21, 2008, at 7:13 AM, Jeff Squyres wrote: Right, but the plpa_solaris_module.c file will need to be updated with the new function signatures so that it will still compile (i.e., if you're going to be changing the function signatures in paffinity.h). Hah -- I meant paffinity_solaris_module.c. :-) -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems
Re: [OMPI devel] PLPA ready?
Yes, I think we should change paffinity.h and paffinity_solaris_module.c and paffinity_windows_module.c . I added those API's some time ago based on the plpa API's. Now, the plpa API has changed and no one uses those API's. (Except me and in the future, maybe Sun guys) So I don't see why not change those API's including their signature in paffinity.h Sharon. -Original Message- From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On Behalf Of Jeff Squyres Sent: Thursday, February 21, 2008 5:19 PM To: Open MPI Developers Subject: Re: [OMPI devel] PLPA ready? On Feb 21, 2008, at 7:13 AM, Jeff Squyres wrote: >> Right, but the plpa_solaris_module.c file will need to be updated >> with > the new function signatures so that it will still compile (i.e., if > you're going to be changing the function signatures in paffinity.h). Hah -- I meant paffinity_solaris_module.c. :-) -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] PLPA ready?
On Feb 21, 2008, at 7:13 AM, Jeff Squyres wrote: Right, but the plpa_solaris_module.c file will need to be updated with the new function signatures so that it will still compile (i.e., if you're going to be changing the function signatures in paffinity.h). Hah -- I meant paffinity_solaris_module.c. :-) -- Jeff Squyres Cisco Systems
Re: [OMPI devel] PLPA ready?
On Feb 21, 2008, at 7:01 AM, Sharon Melamed wrote: 1. Yes, I need both parameters when querying socket and cores. 2. I don't think that sun will concern if we will change the get_processor/socket/core_info because as Pak Lui from Sun said in one of his early emails "I am guessing it will not messing us up because these are the functions that Solaris doesn't really implement yet, right?" Right, but the plpa_solaris_module.c file will need to be updated with the new function signatures so that it will still compile (i.e., if you're going to be changing the function signatures in paffinity.h). -- Jeff Squyres Cisco Systems
Re: [OMPI devel] PLPA ready?
Jeff, 1. Yes, I need both parameters when querying socket and cores. 2. I don't think that sun will concern if we will change the get_processor/socket/core_info because as Pak Lui from Sun said in one of his early emails "I am guessing it will not messing us up because these are the functions that Solaris doesn't really implement yet, right?" Sharon. -Original Message- From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On Behalf Of Jeff Squyres Sent: Thursday, February 21, 2008 4:18 PM To: Open MPI Developers Subject: Re: [OMPI devel] PLPA ready? On Feb 20, 2008, at 7:53 AM, Sharon Melamed wrote: >> I guess I was torn between reporting num_processors/sockets and >> max_socket|core_id. Really, you need both, right? It is possible >> that the number of processors and/or sockets are not contiguous. > I need both *because* the number of processor is not contiguous. In my > case, I have a machine with two sockets. the socket numbers are 0 and > 3. so in num_sockets I have 2 and in max_socket_id I have 3 and I need > those both values. Ok, so it sounds like a paffinity API change is in order. When/if the Solaris plugin comes into effect, I know that they have similar issues (processors may not be numbered contiguously). Do you want to change the API to include both parameters when querying sockets and cores? The Solaris API has these functions, but they're no-ops (returning NOT_SUPPORTED), but we'll need to make their prototypes match. I think PLPA otherwise passes criteria for release. I'll release PLPA v1.1 today and try to get it integrated into the trunk. Sorry it's taken a while... -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] PLPA ready?
On Feb 20, 2008, at 7:53 AM, Sharon Melamed wrote: I guess I was torn between reporting num_processors/sockets and max_socket|core_id. Really, you need both, right? It is possible that the number of processors and/or sockets are not contiguous. I need both *because* the number of processor is not contiguous. In my case, I have a machine with two sockets. the socket numbers are 0 and 3. so in num_sockets I have 2 and in max_socket_id I have 3 and I need those both values. Ok, so it sounds like a paffinity API change is in order. When/if the Solaris plugin comes into effect, I know that they have similar issues (processors may not be numbered contiguously). Do you want to change the API to include both parameters when querying sockets and cores? The Solaris API has these functions, but they're no-ops (returning NOT_SUPPORTED), but we'll need to make their prototypes match. I think PLPA otherwise passes criteria for release. I'll release PLPA v1.1 today and try to get it integrated into the trunk. Sorry it's taken a while... -- Jeff Squyres Cisco Systems
Re: [OMPI devel] PLPA ready?
On Feb 20, 2008 3:01 PM, Jeff Squyres wrote: > On Feb 19, 2008, at 10:12 AM, Sharon Melamed wrote: > > I guess I was torn between reporting num_processors/sockets and > max_socket|core_id. Really, you need both, right? It is possible > that the number of processors and/or sockets are not contiguous. I need both *because* the number of processor is not contiguous. In my case, I have a machine with two sockets. the socket numbers are 0 and 3. so in num_sockets I have 2 and in max_socket_id I have 3 and I need those both values. > > (fwiw: this is specifically what I was referring to when I was talking > about returning the paffinity API) > > -- > > Jeff Squyres > Cisco Systems > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
Re: [OMPI devel] PLPA ready?
On Feb 19, 2008, at 10:12 AM, Sharon Melamed wrote: In the patch you sent the variables: num_processors, num_sockets and num_cores are lost outside the paffinity framework. I need those in the ODLS framework. what do think about the attached patch? I guess I was torn between reporting num_processors/sockets and max_socket|core_id. Really, you need both, right? It is possible that the number of processors and/or sockets are not contiguous. (fwiw: this is specifically what I was referring to when I was talking about returning the paffinity API) -- Jeff Squyres Cisco Systems
Re: [OMPI devel] PLPA ready?
Jeff,
In the patch you sent the variables: num_processors, num_sockets and
num_cores are lost outside the paffinity framework.
I need those in the ODLS framework. what do think about the attached patch?
Sharon.
2008/2/19 Jeff Squyres :
> $%@#$% 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
> API.
>
>
>
> On Feb 19, 2008, at 8:59 AM, Sharon Melamed wrote:
>
> > Jeff,
> >
> > 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
> > parameters.
> > 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 ?
> >
> > Sharon.
> >
> >
> >
> > On Feb 19, 2008 4:31 AM, Jeff Squyres 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):
> >> http://www.open-mpi.org/software/plpa/v1.1/
> >>
> >> 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.
> >>
> >> Thanks.
> >>
> >> --
> >> Jeff Squyres
> >> Cisco Systems
> >>
> >> ___
> >> devel mailing list
> >> de...@open-mpi.org
> >> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >>
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> --
> Jeff Squyres
> Cisco Systems
>
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
Index: opal/mca/paffinity/linux/paffinity_linux_module.c
===
--- opal/mca/paffinity/linux/paffinity_linux_module.c (revision 17442)
+++ opal/mca/paffinity/linux/paffinity_linux_module.c (working copy)
@@ -45,9 +45,9 @@
static int linux_module_get(opal_paffinity_base_cpu_set_t *cpumask);
static int linux_module_map_to_processor_id(int socket, int core, int *processor_id);
static int linux_module_map_to_socket_core(int processor_id, int *socket, int *core);
-static int linux_module_max_processor_id(int *max_processor_id);
-static int linux_module_max_socket(int *max_socket);
-static int linux_module_max_core(int socket, int *max_core);
+static int linux_module_get_processor_info(int *num_processors, int *max_processor_id);
+static int linux_module_get_socket_info(int *num_sockets, int *max_socket_num);
+static int linux_module_get_core_info(int socket, int *num_cores, int *max_core_num);
/*
* Linux paffinity module
@@ -64,9 +64,9 @@
linux_module_get,
linux_module_map_to_processor_id,
linux_module_map_to_socket_core,
-linux_module_max_processor_id,
-linux_module_max_socket,
-linux_module_max_core,
+linux_module_get_processor_info,
+linux_module_get_socket_info,
+linux_module_get_core_info,
NULL
};
@@ -168,18 +168,18 @@
return opal_paffinity_linux_plpa_map_to_socket_core(processor_id, socket, core);
}
-static int linux_module_max_processor_id(int *max_processor_id)
+static int linux_module_get_processor_info(int *num_processors, int *max_processor_id)
{
- return opal_paffinity_linux_plpa_max_processor_id(max_processor_id);
+ return opal_paffinity_linux_plpa_get_processor_info(num_processors, max_processor_id);
}
-static int linux_module_max_socket(int *max_socket)
+static int linux_module_get_socket_info(int *num_sockets, int *max_socket_num)
{
- return opal_paffinity_linux_plpa_max_socket(max_socket);
+ return opal_paffinity_linux_plpa_get_socket_info(num_sockets, max_socket_num);
}
-static int linux_module_max_core(int socket, int *max_core)
+static int linux_module_get_core_info(int socket, int *num_cores, int *max_core_num)
{
- return opal_paffinity_linux_plpa_max_core(socket, max_core);
+ return opal_paffinity_linux_plpa_get_core_info(socket, num_cores, max_core_num);
}
Index: opal/mca/
Re: [OMPI devel] PLPA ready?
I am guessing it will not messing us up because these are the functions that Solaris doesn't really implement yet, right? Last time I check we are still hunting for some stable interfaces in Solaris to implement them. Terry Dontje wrote: 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 API. Jeff can you work with Pak to make sure this doesn't completely mess up Solaris' processor affinity methods in OMPI. --td On Feb 19, 2008, at 8:59 AM, Sharon Melamed wrote: Jeff, 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 parameters. 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 ? Sharon. On Feb 19, 2008 4:31 AM, Jeff Squyres 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): http://www.open-mpi.org/software/plpa/v1.1/ 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. Thanks. -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- - Pak Lui pak@sun.com
Re: [OMPI devel] PLPA ready?
Will do. I stress that it *might* be worthwhile -- I think it at least partially depends on what Voltaire does and whether they think it should change (since they're the first ones using the paffinity API in a meaningful way). If we want to change it, it would probably be good to do so before 1.3 so that the interface can be [at least pseudo-]stable for the 1.3.x series. Just my $0.02... On Feb 19, 2008, at 11:47 AM, Terry Dontje wrote: 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 API. Jeff can you work with Pak to make sure this doesn't completely mess up Solaris' processor affinity methods in OMPI. --td On Feb 19, 2008, at 8:59 AM, Sharon Melamed wrote: Jeff, 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 parameters. 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 ? Sharon. On Feb 19, 2008 4:31 AM, Jeff Squyres 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): http://www.open-mpi.org/software/plpa/v1.1/ 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. Thanks. -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems
Re: [OMPI devel] PLPA ready?
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 API. Jeff can you work with Pak to make sure this doesn't completely mess up Solaris' processor affinity methods in OMPI. --td On Feb 19, 2008, at 8:59 AM, Sharon Melamed wrote: Jeff, 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 parameters. 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 ? Sharon. On Feb 19, 2008 4:31 AM, Jeff Squyres 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): http://www.open-mpi.org/software/plpa/v1.1/ 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. Thanks. -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] PLPA ready?
$%@#$% 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 API. On Feb 19, 2008, at 8:59 AM, Sharon Melamed wrote: Jeff, 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 parameters. 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 ? Sharon. On Feb 19, 2008 4:31 AM, Jeff Squyres 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): http://www.open-mpi.org/software/plpa/v1.1/ 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. Thanks. -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems linux-paffinity.patch Description: Binary data
Re: [OMPI devel] PLPA ready?
Jeff, 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 parameters. 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 ? Sharon. On Feb 19, 2008 4:31 AM, Jeff Squyres 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): > http://www.open-mpi.org/software/plpa/v1.1/ > > 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. > > Thanks. > > -- > Jeff Squyres > Cisco Systems > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
