On Tue, 2008-01-29 at 19:05 +0000, Tang, Changqing wrote: > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Arlin Davis > > Sent: Tuesday, January 29, 2008 12:44 PM > > To: Doug Ledford > > Cc: general > > Subject: [ofa-general] Re: Dapl 2 question/issue > > > > Doug Ledford wrote: > > > OK, I've been working on integrating the latest dapl stuff into our > > > RHEL5.2 product and I've come across what I think is an issue. > > > > > > The dapl-2 code is not compatible with dapl-1 code, and there is a > > > (albeit small, but still it exists) amount of work to > > forward port code. > > > However, you maintained the same library name (aka, libdat) for both > > > dapl-1 and dapl-2. > > > > Yes, I wanted to stay away from renaming on every major > > release if possible. But I can see your point if someone > > wants v1 and v2 development packages on the same system. The > > intention was to provide only the latest development > > environment with older versions supported in libraries only. > > > > That means that, if code were to #include > > > <dat/dat.h> and then link against -ldat, they would get the > > old dapl-1 > > > headers and the new dapl-2 library (assuming the dapl-1 headers are > > > installed, which realistically they need to be until all dependent > > > code has been forward ported to dapl-2). In order for dapl-1 and > > > dapl-2 libraries and devel environments to be installed > > > simultaneously, which is what you need for a seamless > > migration from > > > version 1 to 2, you need different names on the libs. Is there any > > > chance we can get an updated > > > dapl-2 that actually changes the lib name to libdat2.so instead of > > > just libdat.so? > > > > I have no objections to libdat2.so. > > > > James, do you see any issues? Anyone else? > > If it is this way, then all previous linked code must re-link again, even they > are only using basic uDAPL features.
That's true anyway. If you compiled a basic udapl application against libdat.so back when it was a link to libdat.so.1, then that's what got stored in the app. You would have to relink the app against libdat.so.2 for it to ever use the new library. > And HP-MPI dlopen(libdat.so), and call dat_registry_list_providers() to find > the version > number, this function always returns the runtime udapl version. A runtime dlopen is different than being linked against a library, and yes in this case you would now have to dlopen(libdat2.so) and if that fails fall back to (libdat.so). However, given that according to the dapl-1 to dapl-2 porting guide there are several structures that have changed their layout between dat-1 and dat-2, I would think that HP-MPI would have to jump through hoops (either by knowing about both layouts, or by knowing what structures to avoid because they change) in order to support working with either dat-1 or dat-2 at runtime. If anything, that would make me think this is a good example of why they *should* be different library names. > --CQ > > > > > > > -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 > > -- Doug Ledford <[EMAIL PROTECTED]> GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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
