I think we have to make the ABI change opt-in, because not breaking ABI backwards compatibility with existing implementations is one of the big reasons we don't already have an ABI standard. I share Christoph's concern here and prefer not to have a separate header file if we can avoid it. However, if we don't have a new header, we cannot interoperate between old and new ABIs. With a new header, the option exists, although we might not take it. There are other ways to deal with the header situation, such as a separate path, preprocessor macros, etc. There is no best option here. Every variety will cause a problem for somebody, although hopefully we can find an option that only causes minor problems in the worst case. Jeff On Tue, Jan 24, 2023 at 7:06 PM Holmes, Daniel John < [email protected]> wrote:

Hi Christoph,

I think the idea of "mpi_abi.h" is that everyone in the world immediately adds 4 characters to every file that currently has "mpi.h" in it. An opt-in approach.

Another possibility is that "mpi.h" becomes the ABI version of the header and we specify "mpi_impl.h" as the implementation-specific header currently exposed by the implementation. An opt-out approach.

If it's done right, no-one will (need/want to) opt out.

Best wishes, Dan.

-----Original Message----- From: Christoph Niethammer <[email protected]> Sent: 24 January 2023 16:53 To: Holmes, Daniel John <[email protected]> Cc: Jeff Hammond <[email protected]>; [email protected] Subject: Re: [mpiwg-abi] MPI-5 ABI proposal

Hi Dan, Heff,

I am not sure if I like the idea of having another possible header file for *library-only* backward compatibility. From a software installation perspective this looks like a nightmare to me to maintain in parallel. We are just getting rid of one header in Fortran currently. ;)

Regarding the issue Dan brought up: I think it would be good to have at least a chance to check if MPI library and MPI header fit together. One idea here would be to introduce a library routine "MPI_Abi_version()" that returns the API version and having a macro constant MPI_ABI_VERSION in the header, that can be compared.

This will work for applications or a tool to test if the library is build against the same ABI. However, it will not help a library to detect if an application was build with the matching MPI header. :/

Best, Christoph

----- Original Message ----- From: "Holmes, Daniel John" <[email protected]> To: "Jeff Hammond" <[email protected]> Cc: [email protected] Sent: Tuesday, 24 January, 2023 16:45:36 Subject: Re: [mpiwg-abi] MPI-5 ABI proposal

Hi Jeff,

Thanks - I looked through quickly - there's nothing outlandish it there, IMHO - seems sensible/modest.

Slide 9 question "both mpi.h and mpi_abi.h in same program?"

Do you mean "in the same translation unit" or "in different libraries linked together into a single binary" or something else?

I'm thinking that the World model encourages the user to pass a communicator from the place where MPI_INIT was called into each sub-program/library - there must be agreement between them on the type/value.

There are a bunch of what-if scenarios here: passing an MPI_Status from one place to another using a parameter/return value suggests your option 1 is the correct answer there (language copy would work).

Best wishes, Dan.

From: mpiwg-abi <[email protected]> On Behalf Of Jeff Hammond Sent: 24 January 2023 15:01 To: [email protected] Subject: [mpiwg-abi] MPI-5 ABI proposal

As requested, I have made a concrete proposal for the MPI-5 ABI.

https://docs.google.com/presentation/d/1cU9ewMUa7w3eaRVtfzov8NinyjzNSp5nF_pe...

Request edit access if you want to paint the bike shed with me.

Jeff

-- Jeff Hammond [email protected]<mailto:[email protected]> http://jeffhammond.github.io/

-- mpiwg-abi mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi

-- Jeff Hammond [email protected] http://jeffhammond.github.io/