[mpiwg-abi] MPI-5 ABI proposal

[Holmes, Daniel John]

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 <niethammer at hlrs.de> 
Sent: 24 January 2023 16:53
To: Holmes, Daniel John <daniel.john.holmes at intel.com>
Cc: Jeff Hammond <jeff.science at gmail.com>; mpiwg-abi at lists.mpi-forum.org
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" <daniel.john.holmes at intel.com>
To: "Jeff Hammond" <jeff.science at gmail.com>
Cc: mpiwg-abi at lists.mpi-forum.org
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 <mpiwg-abi-bounces at lists.mpi-forum.org> On Behalf Of Jeff Hammond
Sent: 24 January 2023 15:01
To: mpiwg-abi at lists.mpi-forum.org
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_peT92SE8I/edit?usp=sharing

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

Jeff

--
Jeff Hammond
jeff.science at gmail.com<mailto:jeff.science at gmail.com>
http://jeffhammond.github.io/

--
mpiwg-abi mailing list
mpiwg-abi at lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi