Tang, Changqing wrote:
If there is a way to seamlessl work on either version available on the system without asking user for choice, I am OK to change the library name.
If you support 1.1 and 1.2 seamlessly then you have already dealt with some of the issues that will come up with 2.0 changes. You will have to build the proper wrappers around structure/api changes and provide the correct major/minor versions during your open call. The big difference is now you have multiple versions of libdat.so to manage along with multiple versions of providers.
According what you said, we can dlopen(libdat2.so) first, then fallback to dlopen(libdat.so).
Yes, if we change the name and you add support for v2. If you fallback to v1 libdat.so then you should be running in v1 mode and only be linking to v1 providers.
Look at the latest OFED 1.3 dat.conf and you can see options already exist to support both versions. MPI implementations using uDAPL and expecting v1 libraries work just fine, while dtest/dapltest built for v2 also work on the same system.
But we have to claim that HP-MPI xxx version and older does not work with uDAPL 2.0. Currently HP-MPI works seamlessly on uDAPL 1.1 or uDAPL 1.2 system.
Yes, and you also have to claim that you support both 1.1 and 1.2 in today's movie where we have providers/devices running at different versions.
FYI: I will continue to support both 1.2 and 2.0 OFA providers going forward so you can move to 2.0 at your own pace.
-arlin _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
