I would agree (quick - defibrillator for George!). This is like rolling out a
howitzer to remove a dust spec from your floor.
Nathan gave a perfectly reasonable explanation for his choice of name. I know
some of us can be really anal-retentive, but this is going beyond reason. Just
leave the name alone and move on.
On Nov 24, 2011, at 4:19 PM, George Bosilca wrote:
> I was expressing my support to the name-aliasing idea. I can't imagine a more
> confusing experience from a user perspective.
>
> george.
>
> On Nov 23, 2011, at 14:52 , Jeff Squyres wrote:
>
>> Can you explain that a little more? Are you -10'ing the whole concept? Or
>> just renaming xpmem? Or ...?
>>
>> On Nov 22, 2011, at 11:37 AM, George Bosilca wrote:
>>
>>> -10!
>>>
>>> george.
>>>
>>> On Nov 22, 2011, at 08:38 , Jeff Squyres wrote:
>>>
>>>> 1. Personally, I would love to rename the openib BTL to something that
>>>> makes sense and is a current name. By "rename", I include "rename the
>>>> directory" -- so it would be ompi/mca/btl/ofrc, or something like that.
>>>>
>>>> 2. Good point about error reporting. I would think that the component
>>>> (e.g., ofrc/openib BTL) should report the name that was specified by the
>>>> user. But this could be a PITA to implement -- you couldn't just
>>>> hard-code your component name in error messages anymore; there would have
>>>> to be some level of indirection, such as a global variable that the MCA
>>>> base fills in with the name that your component was referred to by.
>>>>
>>>>
>>>> On Nov 22, 2011, at 9:34 AM, TERRY DONTJE wrote:
>>>>
>>>>> So with the aliasing scheme the code for openib would still under
>>>>> ompi/mca/btl/openib but you could access it with -mca btl ofrc? Ok, so
>>>>> when an error happens in the openib btl how does it identify itself?
>>>>> Does it use openib or ofrc? This seems like there could be some user
>>>>> confusion by adopting the aliasing scheme.
>>>>>
>>>>> --td
>>>>>
>>>>> On 11/22/2011 9:22 AM, Jeff Squyres wrote:
>>>>>> Here's what Nathan and I discussed / decided:
>>>>>>
>>>>>> 1. Nathan shied away from the name "xpmem" in case some other shared
>>>>>> memory scheme basically did the same thing as XPMEM (i.e., single copy
>>>>>> techniques). (just FYI: xpmem's setup is a little different from KNEM,
>>>>>> though, so they didn't merge in KNEM support to vader) Hence, he wanted
>>>>>> a neutral name that could apply to xpmem and others. He and Sam have
>>>>>> some possible names that could be suitable ("single copy
>>>>>> ...something..."; I don't remember offhand).
>>>>>>
>>>>>> 2. We've long talked about having an MCA component aliasing scheme.
>>>>>> Perhaps now is the time to do it. Such a scheme would do two things:
>>>>>>
>>>>>> - provide alias names for components. For example, both of the following
>>>>>> would be equivalent:
>>>>>>
>>>>>> mpirun --mca btl openib,self ...
>>>>>> mpirun --mca btl ofrc,self ...
>>>>>>
>>>>>> - automatically register alias MCA parameters. For example, both of the
>>>>>> following would be equivalent:
>>>>>>
>>>>>> mpirun --mca btl_openib_param 1 ...
>>>>>> mpirun --mca btl_ofrc_param 1 ...
>>>>>>
>>>>>> This would solve two problems:
>>>>>>
>>>>>> 2a. Finally be able to rename the "openib" module to something more
>>>>>> sensical; "ofrc", perhaps? ("ofrc" = OpenFabrics reliable connected
>>>>>> transport, as opposed to the existing "ofud" = OpenFabrics unreliable
>>>>>> datagram transport BTL).
>>>>>>
>>>>>> 2b. Rename vader to be xpmem, because it only supports xpmem at the
>>>>>> moment. If that component is expanded in the future to support other
>>>>>> similar single-copy schemes, it can be renamed to some neutral name and
>>>>>> have "xpmem" as an alias.
>>>>>>
>>>>>> Nathan agreed to look into a module aliasing scheme / vader->xpmem
>>>>>> rename after he works the hide-OB1/BTL-descriptor-lengths issue that was
>>>>>> previously discussed on the list. This will likely be in early/mid
>>>>>> December.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Nov 17, 2011, at 8:11 AM, Jeff Squyres wrote:
>>>>>>
>>>>>>
>>>>>>> After having to explain to someone at SC for the umpteenth time this
>>>>>>> week that the "vader" BTL uses the XPMEM transport under the covers,
>>>>>>> I'd like to put forth an appeal to rename the "vader" BTL to be "xpmem."
>>>>>>>
>>>>>>> Here's my rationale for why:
>>>>>>>
>>>>>>> 1. Although we have a history of Star Wars-related names, the "ob1" and
>>>>>>> "r2" components got their names because they're mainly algorithms that
>>>>>>> have no obvious name that describes what they do.
>>>>>>>
>>>>>>> 2. All other components that tie into some back-end system are named
>>>>>>> reflecting the back-end system (e.g., tcp, mx, portals, ...etc.).
>>>>>>> "openib" is the weakest example, but we all know that it was named way
>>>>>>> back when OFED was named "OpenIB", and the name has kinda stuck.
>>>>>>>
>>>>>>> 3. The BTL name "xpmem" follows the law of least astonishment from the
>>>>>>> user's perspective.
>>>>>>>
>>>>>>> 4. Cute names rarely seem so after 6 months.
>>>>>>>
>>>>>>> I'll even volunteer to do the work to rename it (a bunch of file moves
>>>>>>> and global search-and-replaces).
>>>>>>>
>>>>>>> --
>>>>>>> Jeff Squyres
>>>>>>>
>>>>>>> jsquy...@cisco.com
>>>>>>>
>>>>>>> For corporate legal information go to:
>>>>>>>
>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> devel mailing list
>>>>>>>
>>>>>>> de...@open-mpi.org
>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>>>>
>>>>>
>>>>> --
>>>>> <Mail Attachment.gif>
>>>>> Terry D. Dontje | Principal Software Engineer
>>>>> Developer Tools Engineering | +1.781.442.2631
>>>>> Oracle - Performance Technologies
>>>>> 95 Network Drive, Burlington, MA 01803
>>>>> Email terry.don...@oracle.com
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> devel mailing list
>>>>> de...@open-mpi.org
>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>>
>>>>
>>>> --
>>>> Jeff Squyres
>>>> jsquy...@cisco.com
>>>> For corporate legal information go to:
>>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>> jsquy...@cisco.com
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>
>>
>> _______________________________________________
>> 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
