Re: [mpi-21] ABI - call for working group

[Jeff Squyres <jsquyres@xxxxxxxxx>]

On Jan 13, 2008, at 6:51 PM, Greg Bronevetsky wrote:

> > Fair enough. I don't know how this tug-of-war is going to play out.  
> > My expectation is that morphing layers will need little updating  
> > after the initial well-tested releases because the MPI spec changes  
> > rarely and MPI implementations don't come out with ABI-related  
> > updates very often. As such, morphing layers should be a rather  
> > solid part of the software stack. However, this is a hard one to  
> > judge.

In the "FWIW" category: there has actually already been precedent for  
a similar thing: the C++ bindings in MPI.  A public version of C++  
bindings was released, initially as a standalone software package that  
could (and did) sit on top of many different MPI implementations.   
Indeed, the C++ bindings' main operation was pretty analogous to a  
morph layer: convert the C++ API/handles to the back-end C-API/handles.

After a few public releases, the C++ bindings software were  
incorporated into several different MPI's (proprietary and open  
source).  After that, it didn't change much at all.  There were a few  
gnarly parts in the implementation (probably the most complicated  
parts were the dual MPI/PMPI code and the build system, which most  
people did away with anyway), but on the whole, it was a fairly simple  
piece of software.

I expect a morph layer would also be [mostly] relatively simple.  I  
have not seen the MorphMPI or PnMPI codes, but I would expect that it  
would not be too difficult for the MPI community to vette them fairly  
thoroughly.  No piece of software will ever 100% bug free, but it  
shouldn't be too hard to get "close enough" for a community-standard  
morph layer, IMO.

--
Jeff Squyres
Cisco Systems