I could possibly buy your argument Ralph if this was a one off BTL that
only Nathan (and his employer) is going to use. I am assuming though
this is a more general protocol for a vendor specific protocol. Thus it
seems that a sane naming of the BTL is within the realm of the community.
That being said, I think I would agree that Jeff should have passed this
by Nathan first before posting the RFC (which for all I know he has)
just in case there is some background that would convince Jeff that
vader is appropriate.
--td
On 11/17/2011 9:29 AM, Ralph Castain wrote:
Frankly, the only vote that counts is Nathan's - it's his btl, and we
have never forcibly made someone rename their component. I would
suggest we not set that precedent. I'm comfortable with whatever he
decides to call it.
On Nov 17, 2011, at 7:00 AM, TERRY DONTJE wrote:
+1
Isn't there precedent with the other BTLs to name them based on the
messaging protocol they are supporting instead of some movie
character (tcp, openib, shmem, portals, ...).
--td
On 11/17/2011 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).
--
<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 <mailto:terry.don...@oracle.com>
_______________________________________________
devel mailing list
de...@open-mpi.org <mailto: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
--
Oracle
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 <mailto:terry.don...@oracle.com>
