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.

--brad


On Wed, Jul 9, 2008 at 8:49 PM, Jeff Squyres <jsquy...@cisco.com> wrote:

> 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)
>
> --
> Jeff Squyres
> Cisco Systems
>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>

Reply via email to