<div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Jeff</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 24, 2023 at 7:06 PM Holmes, Daniel John <<a href="mailto:daniel.john.holmes@intel.com">daniel.john.holmes@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Christoph,<br>
<br>
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.<br>
<br>
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.<br>
<br>
If it's done right, no-one will (need/want to) opt out.<br>
<br>
Best wishes,<br>
Dan.<br>
<br>
-----Original Message-----<br>
From: Christoph Niethammer <<a href="mailto:niethammer@hlrs.de" target="_blank">niethammer@hlrs.de</a>> <br>
Sent: 24 January 2023 16:53<br>
To: Holmes, Daniel John <<a href="mailto:daniel.john.holmes@intel.com" target="_blank">daniel.john.holmes@intel.com</a>><br>
Cc: Jeff Hammond <<a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a>>; <a href="mailto:mpiwg-abi@lists.mpi-forum.org" target="_blank">mpiwg-abi@lists.mpi-forum.org</a><br>
Subject: Re: [mpiwg-abi] MPI-5 ABI proposal<br>
<br>
Hi Dan, Heff,<br>
<br>
I am not sure if I like the idea of having another possible header file for *library-only* backward compatibility.<br>
>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. ;)<br>
<br>
Regarding the issue Dan brought up:<br>
I think it would be good to have at least a chance to check if MPI library and MPI header fit together.<br>
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.<br>
<br>
This will work for applications or a tool to test if the library is build against the same ABI.<br>
However, it will not help a library to detect if an application was build with the matching MPI header. :/<br>
<br>
Best,<br>
Christoph<br>
<br>
----- Original Message -----<br>
From: "Holmes, Daniel John" <<a href="mailto:daniel.john.holmes@intel.com" target="_blank">daniel.john.holmes@intel.com</a>><br>
To: "Jeff Hammond" <<a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a>><br>
Cc: <a href="mailto:mpiwg-abi@lists.mpi-forum.org" target="_blank">mpiwg-abi@lists.mpi-forum.org</a><br>
Sent: Tuesday, 24 January, 2023 16:45:36<br>
Subject: Re: [mpiwg-abi] MPI-5 ABI proposal<br>
<br>
Hi Jeff,<br>
<br>
Thanks - I looked through quickly - there's nothing outlandish it there, IMHO - seems sensible/modest.<br>
<br>
Slide 9 question "both mpi.h and mpi_abi.h in same program?"<br>
<br>
Do you mean "in the same translation unit" or "in different libraries linked together into a single binary" or something else?<br>
<br>
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.<br>
<br>
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).<br>
<br>
Best wishes,<br>
Dan.<br>
<br>
From: mpiwg-abi <<a href="mailto:mpiwg-abi-bounces@lists.mpi-forum.org" target="_blank">mpiwg-abi-bounces@lists.mpi-forum.org</a>> On Behalf Of Jeff Hammond<br>
Sent: 24 January 2023 15:01<br>
To: <a href="mailto:mpiwg-abi@lists.mpi-forum.org" target="_blank">mpiwg-abi@lists.mpi-forum.org</a><br>
Subject: [mpiwg-abi] MPI-5 ABI proposal<br>
<br>
As requested, I have made a concrete proposal for the MPI-5 ABI.<br>
<br>
<a href="https://docs.google.com/presentation/d/1cU9ewMUa7w3eaRVtfzov8NinyjzNSp5nF_peT92SE8I/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/presentation/d/1cU9ewMUa7w3eaRVtfzov8NinyjzNSp5nF_peT92SE8I/edit?usp=sharing</a><br>
<br>
Request edit access if you want to paint the bike shed with me.<br>
<br>
Jeff<br>
<br>
--<br>
Jeff Hammond<br>
<a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><mailto:<a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a>><br>
<a href="http://jeffhammond.github.io/" rel="noreferrer" target="_blank">http://jeffhammond.github.io/</a><br>
<br>
--<br>
mpiwg-abi mailing list<br>
<a href="mailto:mpiwg-abi@lists.mpi-forum.org" target="_blank">mpiwg-abi@lists.mpi-forum.org</a><br>
<a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi" rel="noreferrer" target="_blank">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div></div>