[Mpi3-abi] Minutes of MPI ABI working group 2/21/08 meeting

[Jeff Brown]

Thank you for taking notes.  You captured the key discussion points quite well.

Here's what I took away from the meeting:
1. the group will initially focus on an MPI ABI for C bindings only 
(can't solve all the worlds problems at once)
    note that this avoids dealing with the fortran compiler symbol name issues
    the goal is run time dynamic link compatibility (just change 
LD_LIBRARY_PATH (for unix))
2. the work to accomplish this is two fold
    - define a reference mpi.h to include "standard" types, scope and 
values for constants
    - ensure consistent linkage conventions (I don't think this is an 
issue on unix platforms)
3. consider a "MPI ABI compliant" certification rather than including 
this in the general MPI 3.0 standard
    frankly I have concerns about this - I'm afraid implementors may 
just blow it off

Next steps:
- come to consensus on working group goals as input to a proposal
- develop a short briefing to convey this for the March meeting

If we need another telecon that can be easily set up.  Let me know if 
you think this is necessary.

Thanks for your participation - we are off and rolling!

Jeff

At 04:33 PM 2/21/2008, you wrote:

>Attendees:
>
>Jeff Brown (meeting organizer), David Daniels (open MPI / LAM 
>developer), Nathan DeBardeleben (Los Alamos), Fredrick Ellis (end 
>user, didn't catch an affiliation), Jeff Squyres (Cisco), Alexander 
>Supalov (Intel), Erez Haba (Microsoft), Kannan Naraasimhan (HP), 
>David Solt (HP)
>
>1. Introductions.
>
>Variety of backgrounds including developers, end users who work with 
>many applications & MPI's, and industry implementers who work with many ISV's.
>
>2. General Statement of Goals:
>
>For reference, here is our original charter as put forth by Jeff B.:
>
>"To define any additional support needed in the MPI standard to 
>enable static and dynamic linkage compatibility across MPI 
>implementations on a target platform for MPI based Applications."
>
>         * avoid separate compiles for each MPI implementation.
>         * note that beyond mpi/application combinations, we also 
> have compiler/mpi combination issues.
>         * possible scopes for our efforts:
>                 - Compile time (should be covered by the current 
> MPI standard)
>                 - Link time (object level compatibility)
>                 - Run time (simply "point" (LD_LIBRARY_PATH, for 
> example) to a different MPI).  Clearly more difficult but 
> potentially more beneficial than link time.
>         * An ABI should reduce the # of executable flavors users or 
> ISV's most provide.
>         * Some ISV's are qualified to a specific build of a 
> specific MPI and they will not benefit for any ABI changes.
>
>3. Languages
>
>Which bindings should be included in our efforts?
>
>         * Should any efforts be directed to all bindings or just C?
>                 - A C-only solution may be perceived as contrary to 
> the style of the standard.
>                 - It was also noted that MPI introduced language 
> bindings in phases, we could follow suite.
>         * Compilers introduce name mangling issues and C++ is 
> particularly difficult do to the inlining that occurs.
>         * Fortran has more manageable name mangling issues, but 
> also has the problem of .TRUE. & .FALSE. definitions.
>         * Appeared to be some consensus that a C-only solution 
> would be a good starting point.
>
>4. Details of what we might define
>
>         * A morph layer vs. a 'true' ABI compatibility.
>                 - morph layer is perceived as additional overhead.
>                 - morph layer is simpler for implementers who may 
> be heavily invested in current header files, etc.
>            [[ NOTE:  I'm unsure if the morph layer is an 
> implementation issue or does it genuinely change our direction ]]
>
>         * Possible targets for standardization:  mpi.h, name 
> resolution of libraries
>                 - Almost any interesting definition of ABI 
> compatibility will need some level of standardization of mpi.h
>                 - If we can just point to a different directory 
> with LD_LIBRARY_PATH, then applications need to be linked against 
> the same library names, regardless of MPI implementation.
>         * Discussion of whether calling conventions are an issue or 
> is it just a matter of fixing mpi.h?
>                 - Most industry standard platforms have a well 
> defined C calling interface.
>
>5. Should ABI compliance be optional?
>
>         * Forcing all implementations to adhere to a standard may 
> be too great a burden to implementers (detracting them from more 
> interesting/useful work).
>         * Some implementations are on hardware or OS where only one 
> implementation exists and is likely to ever exist.  Should they 
> have to 'pay' the cost to claim full MPI compliance.
>         * Appeared to be consensus that ABI compliance and MPI 
> compliance should be separated out:
>                 - An implementation can be MPI compliant even 
> though they are not ABI compliant.
>                 - Similar to mpiexec definition (recommended, if 
> you provide it must look "this way", but not required)
>                 - A separate "stamp/claim" for being ABI compliant.
>
>6. Next steps
>
>         * For this week:                post minutes to e-mail, 
> then Twiki after acceptance.
>         * For next week:                Schedule next conference call
>         * For march meeting:    define the goal of the working 
> group.  Exactly what are we trying to accomplish.
>
>         * General:                      Discuss via e-mail prior to 
> next meeting?
>                 [[ NOTE: did not appear to be a resolution on this ]]
>         * General:                      How will the outcome of our 
> discussions will get turned into a proposal.
>                 [[ NOTE: do we need to assign an owner? ]]
>         * General:                      How will the outcome of our 
> discussions will get turned into actual MPI standard text as the 
> current presentation style of the Standard is derived from its 
> focus on API's (not ABI's).
>
>
>
>
>
>_______________________________________________
>Mpi3-abi mailing list
>Mpi3-abi_at_[hidden]
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi