On 7/11/08 7:48 AM, "Terry Dontje" <terry.don...@sun.com> wrote:
> Jeff Squyres wrote:
>> Check that -- Ralph and I talked more about #1383 and have come up
>> with a decent/better solution that a) is not wonky and b) does not
>> involve MCA parameter synonyms. We're working on it in an hg and will
>> put it back when done (probably within a business day or three).
>>
>> So I think the MCA synonym stuff *isn't* needed for v1.3 after all.
>>
> I am not dead yet!!!
>
> So, there was also the name change of pls_rsh_agent to plm_rsh_agent
> because the pls's were sucked into plm's (or so I believe). Anyways,
> this seems like another case to support synonyms. Also are there other
> pls mca parameters that have had their names changed to plm?
I think you're opening a really ugly can of worms. How far back do you want
to go? v1.0? v0.1? We have a history of changing mca param names across
major releases, so trying to keep everything alive could well become a
nightmare.
I would hate to try and figure out all the changes - and what about the
params that simply have disappeared, or had their functionality absorbed by
some combination of other params?
My head aches already... :-)
Ralph
>
> --td
>> I think the MCA param synonyms and "deprecated" stuff is useful for
>> the future, but at this point, nothing in v1.3 would use it. So my
>> $0.02 is that we should leave it out.
>>
>>
>>
>> On Jul 10, 2008, at 2:00 PM, Jeff Squyres (jsquyres) wrote:
>>
>>> K, will do. Note that it turns out that we did not yet solve the
>>> mpi_paffinity_alone issue, but we're working on it. I'm working on
>>> the IOF issue ATM; will return to mpi_paffinity_alone in a bit...
>>>
>>>
>>> On Jul 10, 2008, at 1:56 PM, George Bosilca wrote:
>>>
>>>> I'm 100% with Brad on this. Please go ahead and include this feature
>>>> in the 1.3.
>>>>
>>>> george.
>>>>
>>>> On Jul 10, 2008, at 11:33 AM, Brad Benton wrote:
>>>>
>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>>
>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
