I think this is very reasonable to go ahead and include for 1.3. I find that preferable to a 1.3-specific "wonky" workaround. Plus, this sounds like something that is very good to have in general.
v1.3 RMs: Due to some recent work, the MCA parameter mpi_paffinity_alone disappeared -- it was moved and renamed to be opal_paffinity_alone. This is Bad because we have a lot of historical precent based on the MCA param name "mpi_paffinity_alone" (FAQ, PPT presentations, e-mails on public lists, etc.). So it needed to be restored for v1.3. I just noticed that I hadn't opened a ticket on this -- sorry -- I opened #1383 tonight.
For a variety of reasons described in the commit message r1383, Lenny and I first decided that it would be best to fix this problem by the functionality committed in r18770 (have the ability to find out where an MCA parameter was set). This would allow us to register two MCA params: mpi_paffinity_alone and opal_paffinity_alone, and generally do the Right Thing (because we could then tell if a user had set a value or whether it was a default MCA param value). This functionality will also be useful in the openib BTL, where there is a blend of MCA parameters and INI file parameters.
However, after doing that, it seemed like only a few more steps to implement an overall better solution: implement "synonyms" for MCA parameters. I.e., register the name "mpi_paffinity_alone" as a synonym for opal_paffinity_alone. Along the way, it was trivial to add a "deprecated" flag for MCA parameters that we no longer want to use anymore (this deprecated flag is also useful in the OB1 PML and openib BTL).
So to fix a problem that needed to be fixed for v1.3 (restore the MCA parameter "mpi_paffinity_alone"), I ended up implementing new functionality.
Can this go into v1.3, or do we need to implement some kind of alternate fix? (I admit to not having thought through what it would take to fix without the new MCA parameter functionality -- it might be kinda wonky)
devel mailing list