[ofa-general] Re: Dapl 2 question/issue

[Doug Ledford]

On Tue, 2008-01-29 at 19:05 +0000, Tang, Changqing wrote:
> 
> > -----Original Message-----
> > From: general-bounces at lists.openfabrics.org
> > [mailto:general-bounces at lists.openfabrics.org] 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
> > general at lists.openfabrics.org
> > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> >
> > To unsubscribe, please visit
> > http://openib.org/mailman/listinfo/openib-general
> >
-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20080129/ae1cc180/attachment.sig>